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

Re: QA pop quiz

>> Colin Watson <cjwatson@debian.org> writes:

 > I don't know of a source for the composite Provides/Conflicts/Replaces
 > trick, but it's easy enough to build it up from the definitions of each
 > of those fields. Policy 7.5.2 says that Conflicts/Replaces allows one
 > package to say that another should be removed, and renaming is identical
 > to introducing a new package which forces the old package to be removed.

 Oh.  You meant *that*.  Yes, that's documented, c.f. 7.3. (which
 somehow suggests that CR is enough).

 What I meant was an automated mean of upgrading package A to package B
 without having the user select the later explicitly.  Traditionally
 this has been accomplished by fooling arround with dependencies, so
 that the new package is pulled in and the dependencies system removes
 the old one automatically.  This works for packages deep down in the
 dependency chain.

 I haven't had the time to actually figure this out, but I have the
 hunch that a significant portion of the potato -> woody upgrades won't
 be as smooth as desired because of this.  I might be wrong, I might
 just have lost the big picture, having been bitten too many times by
 impossible upgrade paths along the woody development cycle.  A recent
 one involved libsdl.  I don't know what Branden & Co. figured out (and
 I really missed, among all that noise, the reasoning for the .debian
 extension), but I have had to upgrade libsdl packages by hand recently,
 'apt-get install libsdl-whatever' just works, without deinstalling
 anything besides the old libsdl packages, but for some reason apt-get
 (dist-)upgrade won't work.  The xpm packages are in a similar
 situation, last time I looked.

 > For most such problems, I would be liable to pick 'important' or
 > 'normal', depending on the degree to which things break due to the
 > bug.  Examples of these might include Debian's ssh client being
 > unable to talk to some particular commercial ssh server, or tar
 > producing archives that can't be read by some other tar
 > implementations.

 Three concrete examples:

 * Debian box as a NFS client to IRIX [mostly non-issue now].  Allegedly
   this is a bug in libc6, which upstream won't acknowledge (sadly the
   justification boils down to "that's crap").  There's a workaround at
   the kernel level, which won't get merged into the kernel because
   "that's a libc thing" (at least last time I looked at the discussion
   closely).  End-effect is that out-of-the-box Debian using 2.4 won't
   work as a NFS client with IRIX servers.  Ben did apply the patch at
   some point, so you can count this one as solved.

 * Debian's libqt with OpenGL widgets won't work with RedHat's libqt
   with OpenGL widgets because the sonames differ.  Debian's at fault.
   Allegedly compiling the OpenGL widget's into Qt makes KDE unstable.
   IOW, since every single KDE application ends up linked to libGL, and
   some implementations perform initialization even if the application
   doesn't make a single OpenGL call, you end up with some mess which
   eventually produces a segfault (this is the plausible explanation,
   the other ones are just too loony to consider).  Debian's solution
   has evolved over time, and the current one settled in.  The
   consequences are not only inability to run binaries from one distro
   on the other, but the link lines are also affected, forcing software
   authors to special-case Debian.  The problem affects only Qt 2, not
   Qt 3.

 * libc6 is not backwards compatible, that is, in general programs
   compiled against a new libc6 won't run with older versions carrying
   the same soneme, even old Debian ones.  Upstream's take: bad luck,
   libc6 is only forwards compatible.

 From the examples, the scope is obviously too broad to code into
 policy.  The first example is arguably of low visibility.  The second
 one is going to become more visible as time passes by, but since Qt 3
 is not affected, it won't become an issue ("I get link errors",
 "install libqt3-dev").  Regarding the third one, Debian can't do
 anything about it and it fades into LSB's realm.

 The other kind of interoperability issues, the ones you mention, are
 more visible, and I hope that if they ever make into Debian, they won't
 stay for long due to sheer user/developer pressure.

 > Is that a specific enough answer? I have a feeling you meant
 > something a little less general than that.

 Acutally I was thinking about the general case and wanted a bit of input
 from other people.  Thanks,

Marcelo             | Until an unfortunate axe incident, Gloria had been
mmagallo@debian.org | captain of the school basketball team.
                    |         -- (Terry Pratchett, Soul Music)

Reply to: