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: