On Sat, Jun 18, 2005 at 10:33:06PM -0400, Joey Hess wrote: > Except unstable is capable of running packages built on stable
Trivial packages which only link against libc, yes. In general, no. And many packages from unstable won't build correctly (or at all) on stable during most of the release cycle. > , and stable is to some extent (partial upgrades) capable of running > packages built on unstable. This is not the same thing. "binary compatible" package installations do not require upgrading system libraries. > And if it doesn't work, a dependency will tell you it doesn't work. Usually, yes, but I don't see the relevance. dpkg can tell you that a binary built with glibc 2.3.2.ds1-21 can't be installed on a glibc 2.3.2.ds1-20 system, but this doesn't change the fact that the package is not compatible with your system. > If I were only interested in source code, I would not be a contributor to > this distribution. I am interested in whole, working systems which are > accessible to end users. That's interesting, but not particularly relevant. Of course source code isn't the only medium which matters. I only said that it isn't important that binary packages be universal. > No, Debian packages just work, if dpkg allows you to install them on > your system. I disagree, but again, I don't see your point regarding dependency checks. Either the package is compatible, or it isn't. The fact that the tools can detect some types of incompatibilities and say "no" doesn't make the packages any more or less compatible. > Unless, now, they happen to be built by someone running the other > distribution. The only incompatibilities being discussed in this thread have involved incompatible package dependencies, but you seem to be alluding to some other type of incompatibility. Are you concerned about the pkgstriptranslations example you describe below, or something else? > Just as a random example, Ubuntu's fork of debhelper has a hack[1] in > dh_buildeb to run pkgstriptranslations, an Ubuntu-specific command which > removes mo files from usr/share/locale. That works ok until Debian adds > a pkgstriptranslations that does something else. That would be a bit pathological, don't you think? Ubuntu also has a binary called gcc-4.0, but I wasn't concerned about Debian creating a gcc-4.0 which did something else. > Or until the Debian version of debhelper is installed on someone's Ubuntu > system and begins building packages without calling this tool. This particular scenario causes no problem, and works as designed (though in general, mixing packages from derivatives is not a smart thing to do for other reasons). > No other distribution has ever seen the need to fork debhelper The content of the "fork" helps put this in perspective: http://people.ubuntu.com/~scott/patches/debhelper/debhelper_4.2.33ubuntu1_unknown.patch > (and modify/fork 1500 other packages), or recompile the entire Debian > archive from scratch. But today there do now exist Debian derivatives which want to do such devious things as support different versions of Python than Debian. > No other distribution except perhaps Knoppix has attracted enough users > and developers to make compatability issues more than minor annoyances. Is there a reason why you don't have a problem with Knoppix, but you object to Ubuntu? What about the other Debian derivatives which are based on snapshots of testing or unstable (even packages from experimental), equally incompatible with stable Debian releases? > [1] which I would not accept into debhelper if asked because it violates > design principles of dh_builddeb I'm not sure that we need this patch going forward, but at any rate it's extremely simple and got the job done. -- - mdz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
