[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Imlib NMU



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.  

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?

In other words, I think those packages don't directly link in
libjpegg6a, only indirectly via imlib (after all, they're using imlib
for the image manipulation, so why should they need libjpegxxx
directly?)


Forcing a package to depend on an older version will lead to a situation
where everyone is waiting on someone else to make the first move; if for
example gmc is rebuilt, it will still depend on libjpegg6a, because the
current imlib stuff still depends on libjpegg6a. However, what I read
from your message is that an imlib that depends on libjpeg6b must not be
uploaded because there are still packages that depend on libjpegg6a.
Chicken and egg problem a.k.a. circular dependencies.

Do you see the problem? After all, slink is "unstable"; you can expect
this sort of thing to happen... It's just necessary that those packages
that use imlib have to be rebuilt.  It worked fine on the Alpha
architecture, where we can do that in one swell foop.


Paul Slootman
-- 
home: paul@wurtel.demon.nl | work: paul@murphy.nl | debian: paul@debian.org
http://www.wurtel.demon.nl | Murphy Software,   Enschede,   the Netherlands


Reply to: