[PlanetCCRMA] PlanetCCRMA and Red Carpet

[Fernando Pablo Lopez-Lezcano]

> Thank you for the feedback. The problem was indeed the db1 vs db4 stuff,
> but all I want is to find a package manager able to work both with
> Ximian and Planet, because they provide two wonderful set of packages.
> 
> > In a nutshell, they _force_ the install of a package that is obsoleted
> > by one of the original RedHat packages, and then anyone (not just Planet
> > CCRMA) trying to use a package manager that relies on proper package
> > dependencies can't.It is a BIG no no. I would say, bad monkey, no cookie
> > :-)
> 
> I don't want to enter an endless discussion

Don't worry, me neither :-)

> but the problem seems
> apt-get related: other rpm package managers don't complain. Why is db1
> only obsoleted by db4 with apt-get?  No problem with the plain rpm
> command, red carpet or yum. Yum is great, but there is no yum repository
> for Planet. 

Not yet, I have to do that (I keep saying that, but there are always
other things that have higher priority - right now packaging a newer pd
and pd externals which I've said I'd do a long time ago :-). 

Let's see how I can make this concise and purely technical. 

First, the problem:

I just downloaded the Ximian db1 package just to make sure I know what
I'm talking about :-) and I found the situation different than what I
expected. There are two problems with installing the Ximian db1 package
for RedHat 9 on RedHat 9. 

a) RedHat's db4 obsoletes db1 and db1-devel:
# rpm -q --obsoletes db4
db1
db1-devel

b) Ximian's db1 conflicts with files already installed by RedHat's
   gnome-libs package. The files are:
   /usr/bin/db1_dump185
   /usr/lib/libdb1.so.2 (the db1 library itself)

To clarify problem a), the RedHat db4 rpm package "obsoletes" db1. That
means: if you have installed db4 you cannot install db1 at the same
time. This constraint is part of the db4 rpm itself and was put there by
the RedHat packagers (I don't know the reason, probably because the db1
library is already part of gnome-libs). This constraint is independent
of what you use to install rpms (rpm itself, apt, yum or red carpet -
they all end up using the same rpm libraries either directly or
indirectly). 

The difference is how the "front ends" deal with the broken dependency.

Rpm: If you install other packages using rpm (other than db4 or db1) rpm
will not complain even though there is a broken dependency or you forced
an install. If you manually uninstall db1 and try to install it again
you will see that rpm will refuse to do that. You can bypass the
dependency check with the "--nodeps" flag and the file conflicts with
"--force" and get db1 installed anyway (that must be what the Ximian
installer is doing behind the scenes), but then you are, in this case,
overwriting RedHat binaries with your own - not good at all). 

Yum: I don't know too much about yum but from what I understand it
reacts in the same way that rpm does (ie: it can install a package
unrelated to a broken dependency). 

Apt: apt is more picky. It will not install packages if the dependencies
in the system are not correct. Personally I think that is a good choice.
You can argue both ways. But broken dependencies are bad. 

Open Carpet: don't know about this one. Obviously it ignores problems
like db4 vs. db1 as they are the originators of this one :-) 

Solutions:

Obviously Ximian does not think there is a problem. As a packager I say
there is. There is no reason to willingly break dependencies or force
installs. I don't know whose fault it is. On one hand RedHat is
including a db1 library binary within gnome-libs. That does not look
like a good choice, they should have a separate db1 package. On the
other hand Ximian is not trying to work around the problem, it is just
stomping on it and breaking packages that are not Ximian's (and apt as
well). 

The fix should involve the two parties, a fixed db4 package that does
not obsolete db1, a proper db1 package and good packaging on the part of
Ximian. 

No easy way out, I guess. 
And I said I was going to be concise. 
Sorry for the wasted bandwidth......
-- Fernando