[prev in list] [next in list] [prev in thread] [next in thread] 

List:       mandrake-cooker
Subject:    [Cooker] [Bug 581] [mozilla] Version 1.2 requires libgtk+-x11-2.0_0
From:       "[Bug 581]" <bugzilla () linux-mandrake ! com>
Date:       2002-11-30 14:36:44
[Download RAW message or body]

https://qa.mandrakesoft.com/show_bug.cgi?id=581





------- Additional Comments From bgmilne@cae.co.za  2002-11-30 15:36 -------
OK, it seems you have some misconceptions about a lot of issues, and the only
reason I am going to reply to this is so that we can refer to this bug in the
future for others.

(To the cookers, who are cc'ed on bug reports, this probably indicates the need
for an FAQ on cooker, sorry to waste your time with this, but maybe someone can
collect some of this).

> Yes, others have made the same sort of silly comment to me via email and they
> all seem to be based on the same peculiar idea.  Its the old "If we can't
> achieve perfection then we shouldn't do anything at all." argument all over 
> again.

Any comments you received by email were probably not silly, as you should see.
The point isn't that Mandrake doesn't strive for perfection, it's that cooker
isn't meant for updating a stable release, and supporting people who think it
is. It's for the *next* release, and your comments are invalid in this light.

> However, isn't
> the entire point of Cooker that it allows the user community to find and 
> resolve problems so as to save Mandrake the effort?  

Yes, but this only applies if said 'community' are running cooker. I run cooker
on one box, and stable on another. Many other people (most subscribers/posters
on the cooker list) run cooker, probably many more outside Mandrakesoft than inside.

> If through the efforts of users
> SOME of the incorrect dependencies in SOME of the RPMs were fixed then would
> this be such a bad thing?

Cookers do help fix dependencies, in fact someone tracked down a subtle one just
this week. But you are assuming that you found a valid dependency.

Its not as if (as one person suggested) Mandrake don't believe in sub-version
dependencies.  Let's take a couple of examples.

> $ rpm -q --requires gimp | grep = | grep -v rpm
> gtk+ >= 1.2.8
> glib >= 1.2.8
> libgimp1.2 = 1.2.3-17mdk

These are explicit dependencies, which were added by the developer by hand.
Usually this occurs when the packager knows that there is no way the package
will work (ever) without the dependencies. So they are listed in the spec file.

Implicit depencies (highlighted by Goetz above) are not determined by the
packager or listed in the spec file, because they can change depending where
they are compiled. These dependencies are created automatically  when the rpm is
built, using the output of ldd:

(here is an example using samba):
[bgmilne@bgmilne bgmilne]$ rpm -qR samba3-server|grep "acl"
libacl.so.1
[bgmilne@bgmilne bgmilne]$ ldd /usr/sbin/smbd3|grep acl
        libacl.so.1 => /lib/libacl.so.1 (0x40027000)
[bgmilne@bgmilne bgmilne]$ urpmf /lib/libacl.so.1
libacl1:/lib/libacl.so.1
libacl1:/lib/libacl.so.1.0.0
[bgmilne@bgmilne bgmilne]$ rpm -q libacl1
libacl1-2.0.11-1mdk


So, since when this rpm was compiled, the acl library with major version of 1
was installed, and linked against, the binary will need this library to work.
rpm then adds this dependency. Normally, when binary-compatability will be
broken, the library major number should be incremented, but this is not always
the case. Also, there can be other issues (compiler versions etc) which can play
a role.

Now, I (who currently packages samba3) am not going to add a dependency to samba
for libacl1 >= 2.0.11 for no reason, since I know this package still compiles
just fine on Mandrake 8.1, which has libacl1=1.1.2-2mdk. The rpm compiled on
Mandrake 9.0 probably won't work on Mandrake 8.1, but it will work if I rebuild
the SRPM on Mandrake 8.1, and it will pick up the right implicit dependency.


> If Mandrake made this change to the Mozilla RPM then who would lose?  All 
> they have to do is make a one line change to the RPM SPEC file.  Its not as 
> if they have to test the change, since it simply makes explicit the 
> dependency which is implicit in the requirement that one not mix cooker and 
> 9.0.  Plus, if they decide to release Mozilla 1.2 as an update to 9.0, then
>  one potential bug will already have been fixed.

It's already enough work to maintain RPMs as it is, and there is no need to add
these dependencies. Adding one extra now, added up over time (every time someone
reports a different version) eats time, that could rather be spent on packaging
more software or doing other development work (or fixing real bugs).

You will notice, if you take the time to rebuild the mozilla SRPM, that the
resulting RPM will work just fine on your 9.0 box. This proves that there is not
point in adding extra, incorrect dependency information to the RPM.

> I have to say that the whole thing smacks of the "We have a fix for this bug
> but we're not going to apply it because it doesn't say in the contract that 
> we have to." attitude that drives me crazy when I deal with software 
> contractors at work.

Let's not make any judgements until you have rebuilt the mozilla SRPM from
cooker on your box, and seeing if you are correct in your assesment of the problem.

> On a related topic how do we know that packages don't have dependencies 
> which they don't actually need?

See above, the ldd output.

> Example: recently I wanted to install kdegraphics and I ended up having to 
> install heaps of software for digital cameras, scanners and usb ports 
> together with all their associated libraries, despite the fact that I don't 
> have any of that hardware.

Would you rather have the software not work due to a missing library. The
problem here is that too many different binaries are packaged in kdegraphics,
and dealing with a lot of hardware. A solution to this would be to split
kdegraphics, but that would make a lot more maintenance work. I am sure Laurent
(who maintains KDE for many releases of Mandrake) will take your offer to
maintain KDE for all the releases he does if you want to make this change. He
may maintain it if someone does the initial split (it took about 3 months for
one of the cookers patches to the kde-devel packages to make it in, so now you
don't need all the database servers installed for qt development), but the
chances are slim.


> If you think about it for a while, you will see that as long as one adds 
> new dependencies and doesn't remove ones that aren't needed then eventually
> the distribution will turn into one amorphous blob.

This is a real problem, and one that hasn't yet really been solved.

> BTW, don't forget that I didn't suggest adding a dependency to Mozilla, 
> simply updating one that was already there.

The one that was there was added automatically at compile time and works
whereever it is compiled. If I compiled the RPM on Mandrake 8.2 (with the RPMs
available from the Club), it would be correct. If I compiled it on 9.0, it would
be right. You are suggesting changing this to a hard-coded manual dependency
which would not work right on all those distros.

Now, maybe you will consider that maybe everyone else replying to you about
running cooker RPMs on 9.0 might have been correct. If you want to be of any
help in improving the distro, you should not mix binaries from cooker and 9.0.
And if you are going to, you had better be very sure that this is not the cause
of your problems, otherwise you will end up wasting everyone's time. If you
don't have the bandwidth to run cooker, wait until the beta series for 9.0.
There are also many other areas you can contribute, including Mandrakeexpert,
the mailing lists, and the alt.os.linux.mandrake newsgroup.

I hope you were not offended by my post, that you learnt something, and that you
will find some way to contribute to the Mandrake community. BTW, if you are a
MandrakeClub member, you may want to vote for the Mozilla-1.2 request for 9.0,
and maybe someone will give it more attention. When the RPM from club is tested,
it will then be available publicly, as cdbakeoven, kopete, gfm, mysqlcc, sqlgui,
quakeforge, and a few others are (for example, at
ftp://ftp.sun.ac.za/mandrake/mandrake-devel/unsupported/MandrakeClub/9.0/i586/).

Let's hope that we don't have to cover all this ground again ...

Buchan



------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

[prev in list] [next in list] [prev in thread] [next in thread]