On 6/20/05, Ian Murdock <[EMAIL PROTECTED]> wrote: > On 6/18/05, Michael K. Edwards <[EMAIL PROTECTED]> wrote: > > In any case, Ubuntu packages aren't Debian packages any more than > > Mandrake packages are Red Hat packages. > > If Ubuntu sees itself to Debian as Mandrake was to Red Hat, then that > certainly explains a lot.
Well, I haven't used Mandrake in a while, and if there's bad blood there that I don't know about then it's probably a bad analogy. (And remember, I have no affiliation with Ubuntu either.) All I'm saying is that, unlike a CDD or a Debian-pony-with-one-extra-trick (Knoppix, etc.), Ubuntu is a full distro which tracks Debian at the source code level rather than using Debian binary packages. This has consequences for ISVs not unlike those of the early Mandrake releases, when Mandrake tracked Red Hat's code and releases but optimized for Pentium and wrote an alternate installer. If you wanted your third-party application to run on both, you couldn't just sort of pretend you were part of the Red Hat release cycle; you needed to concoct a build environment whose products were distro-agnostic. Choice is good; but choice doesn't always make things easier. > > If you want binary > > compatibility, you need to build a system whose engineering outcome is > > binary compatibility > > That's precisely what I'm proposing we should do here! There will never > be a better time. Building that system doesn't mean cajoling Ubuntu into holding breezy back. It means (as I see it) constructing an apt repository and a debootstrap recipe for Debian Standard Base 05.03 and 05.09 -- build environments for sarge+hoary+breezy+etch-compatible binary debs and breezy+etch-compatible debs respectively. Presumably packages built in 05.03 won't be able to use ABI fixes, etc. introduced at the last minute in sarge and/or hoary, and anything that we can already tell won't run on breezy or etch should also be excluded. If that leaves a build environment that won't build much other than C programs with few library dependencies, maybe we should think about formalizing more backwards compatibility mechanisms in breezy/etch. If, that is, we care about ISVs and other poor sods who don't want their application upgrade cycle dictated by their O/S upgrade cycle (and vice versa). Cheers, - Michael