>> Colin Watson <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED] | captain of the school basketball team. | -- (Terry Pratchett, Soul Music)