Re: Debian concordance
On 6/20/05, Ian Murdock <imurdock@gmail.com> wrote:
> On 6/18/05, Michael K. Edwards <m.k.edwards@gmail.com> 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
Reply to: