Re: Imlib NMU
Paul Slootman <paul@wau.mis.ah.nl> writes:
> On Sun 04 Oct 1998, Brian Almeida wrote:
>
> > I just talked to Shaleh, the previous Imlib maintainer. It was
> > intentional to use libjpegg6a for imlib. 6a and 6b do not play
> > well together. Your NMU
> Is it necessary that they play _together_ ?
> > breaks every Imlib-using GNOME package out there. Therefore I am
> > overriding it. Please go through the correct channels next time,
> > instead of going out and doing NMUs of other peoples packages
> > without a so much as a by-your-leave. That is the whole point of
> > the Bug tracking system. I check my mail regularly, as does
> > Shaleh. Let us know before you go out doing stuff that affects
> > other people's packages. Going to libjpegg6b is fine. But all
> > the other packages have to make it there as well.
Please people, don't upload NMUs without at least trying to discuss it
with the developer. If I wanted to deal with "anyone can upload a new
version anytime he/she feels like it", I would be making RPMS.
I recently had somebody completely break my dhcpcd package by
uploading a completely different dhcpcd daemon with much larger
version number. They didn't even ask me. If they had asked me, or
looked at the bugs filed against the package, they would have found
out where to get an experimental package of the thing they uploaded,
packaged correctly. (I had to introduce epochs to override the NMU.)
> Do you really mean _all_ other packages? AFAIK you can have libjpegg6a
> and libjpeg6b installed together (I didn't find a libjpegg6b package).
> Additionally, isn't it that so that those packages that use imlib and
> depend on libjpegg6a, depend on libjpegg6a only because imlib does?
libjpeg6b is broken and shouldn't be used by any new packages. It
doesn't respect the upstream maintainers choice of soname, namely
libjpeg.so.62, and hence makes Debian incompatible with Red Hat.
(RedHat does use the the upstream soname.) Until somebody gets around
to releasing a "libjpeg62" package, we should stick with libjpeg6a.
Last I knew it was an unwritten Debian policy to respect upstream
sonames whenever possible. (It takes an effort to get libjpeg-6b to
compile with anything other than the upstream soname, so I suspect the
maintainer just blindly applied the 6a diff file without noting that
they added shared library support in 6b.)
Steve
dunham@cse.msu.edu
Reply to: