Re: "Freezing" non-free and contrib
email@example.com (Winfried Truemper) wrote on 17.12.96 in <Pine.LNX.3.95.961217003300.18872Rfirstname.lastname@example.org>:
> On Mon, 16 Dec 1996, Lars Wirzenius wrote:
> > > One solution to this problem could be a directory ".everypackage" that
> > > is not visible to the user but contains all packages.
> > This would make it really painful to mirror only, say, frozen and
> > unstable, but not stable. So it's not workable.
> If we assume that the links are updated automatically in the new directory
> tree (every other approach would be the hell for the maintainter), it
> would we possible to create an actual file-list for each release which
> could be used by the mirror-sites to fetch only certain files.
This is a huge pain to handle.
> > If we don't have code names, when we start work on version 2.0, we
> > will have to create a directory called 2.0. This will confuse people,
> > since it is not clear whether 2.0 has been released or not.
> How do you know from a codename like "bo" or "rex" if it's released or
> not? I didn't refer to the links "stable" and "unstable", they are a must.
The idea is that you *should not* know from the code name. In fact, you
should not use the code name; you should use the link.
"Trust the link. The link knows."
That was the main idea behind inventing the code name scheme. If people
can know from looking at the directory name, then we would need to rename
directories (causing mirrors to refetch). So knowing from the directory
name is out anyway; the code names insure that people don't even try.
Personally, I would have gone one step further - I'd have put all the
codename dirs into one subdir, so they wouldn't even appear in the
distribution root directory (which is already too cluttered as it is - a
ls ought to fit on one screen page).
> So I wouldn't mind if packages in .everypackage would be a link into "rex"
> until it is superceeded by "1.3" (or whatever it will be called). (This
> way we could avoid re-transferring megabytes of data.)
> Cleaning up the directory structure step by step but being compatible is not
Actually, this was the method Debian used to migrate to the current setup.
It also uses it today for switching over to new codename directories.
Congratulations for reinventing the wheel; I prefer the original, though -
it's got less edges.
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
debian-devel-REQUEST@lists.debian.org . Trouble? e-mail to Bruce@Pixar.com