Re: Suggestion: Skip Slink!
On Wed, Jan 06, 1999 at 12:35:58AM -0500, Avery Pennarun wrote:
> > No, that's not proper either. Debian is a set. Hamm was a multi-CD set:
> > i386, m68k, contrib, sources, etc. Debian is not Debian if it's missing
> > for a particular platform. (Again, exceptions for platforms just starting
> > out and truly not ready for release.)
>
> I disagree. If slink/i386 is called "frozen" but is exactly the same
> version as it will be when it is released, then it might as well be
> released. If slink/sparc isn't ready at that point, it's not a "missing
> part", it's just a late one.
This is not the point I was making, but even your point is incorrect.
Abstractly, one could say that Sparc is frozen but the FTP site hasn't been
updated for it yet. (In fact, we did just that for i386...)
My example was if there is a problem in one (actually, that may have been
your example.) A release-critical bug in a frozen sparc should hold up the
i386 release.
> You are saying we should inconvenience thousands of people who could be
> using slink/i386 today (in our imaginary world) except that the
> irrelevant (to them) slink/sparc isn't ready.
I am saying that we should not sacrifice one platform for the benefit of
another. Period.
I don't give a hoot if i386 people have to wait a few days because of m68k
problems. Neither do I care of Alpha has a wait a few days because of a bug
that only appears on i386.
> > Also don't forget that the source CDs contain source for *all* archs. It
> > may not be possible to get accurate source CDs if different archs are
> > released at different times, putting Debian and CD vendors in the position
> > of violating GPL. Bad, bad, bad.
>
> Violating the GPL? If packages are different between i386 and sparc (which
> they regularly are, since non-i386 arches have fewer developers yet), then
Or because the i386 sources regularly do not work on other platforms due to
bugs in them. (the i386 sources, not the other platforms)
> the FTP site already violates the GPL by not including two different source
> archives (or diffs). We know about that, it'll probably get fixed sometime.
Indeed, and I am firmly opposed to making any release that suffers from this
serious problem.
> Meanwhile, releasing a CD with the same files on it is no better or worse.
It is worse becuase the problem occurs in more places.
> Once the problem is fixed, CD's won't violate the GPL if the FTP site
> doesn't.
Yes they could. Consider a hypothetical release of i386 without Alpha.
There are some packages that run ONLY on Alpha, such as MILO. The source CD
would not have that source, or may have an old version. When Alpha comes
out, it's *supposed* tohave the same source as i386, but obviously it won't
-- otherwise, it would have been released at the same time.
> >From the point-of-view of an administrator, I can see big advantages in
> having exactly the same package versions in slink/i386 and slink/sparc --
> that way I can run a heterogeneous network really comfortably, expecting the
> same bugs/features on all platforms.
Indeed.
> However, if slink/sparc is released with a few changes after slink/i386,
> there's nothing stopping the i386 people from rebuilding their packages with
> sparc's changes in order to catch up. We just call that Debian 2.1r2, and
> sparc never made a 2.1r1 release. If I'm an admin concerned with
> consistency, I stayed with hamm until all my required arches were stable.
This logic only works if you happen to use FTP.
>
> Have fun,
>
> Avery
--
John Goerzen Linux, Unix consulting & programming jgoerzen@complete.org |
Developer, Debian GNU/Linux (Free powerful OS upgrade) www.debian.org |
----------------------------------------------------------------------------+
Visit the Air Capital Linux Users Group on the web at http://www.aclug.org
Reply to: