Re: naming convention question
John Hasler writes:
> Buddha Buck writes:
> > It was seen that one reason for this was that someone looking at the FTP
> > site, seeing a directory with a numbered version would think that that
> > version was ready for release. A policy decision was made to name
> > releases while in development, and only number them when released.
>
> "unreleased-1.3" and "unreleased-2.0" would be more useful and less
> confusing.
Maybe, but it makes life hard on mirror sites.
Before we went to the current scheme, there was a time when the main
directories were "stable" (i.e., released, ready to go, and in theory,
unchanging), and "unstable" (i.e., a moving target, a future release,
not yet fully ready). When "unstable" got renamed "stable", all hell
broke loose at mirror sites.
Mirror software can't tell the difference between a renamed directory
and a new directory with new files in it. So when "unstable" vanished
and "stable" changed drastically, the mirror sites dutifully downloaded
all the new stuff under stable (which was already under unstable, but
the mirror sites couldn't tell), and then deleted the files it already
had under unstable. This tied up a tremendous amount of network
bandwidth, and everybody involved complained bitterly (and for good
reason).
Now we use symbolic links to manage the release names (stable currently
points to bo, and unstable points to hamm). When we release hamm,
stable will change to point to hamm, and the mirror sites only have to
deal with one or two small symbolic link changes, not downloading the
entire distribution again.
Symbolic links are crucial for managing the distribution. A month ago
or so, we had three distributions on ftp.debian.org: rex, bo , and
hamm. Since hamm is bigger than bo, and bo was the first distribution
to require 2 CD's to distribute, without symbolic links between the
three distributions the whole mirror site would be over 1.5GB in size.
By using symbolic links, we can usually eliminate a major chunk of that
-- when a new distribution is created, it is initially populated with
symbolic links to the old distribution (which makes the new
distribution quick to mirror, and small in size), and as the packages
are upgraded, the new distribution fills up. If we renamed the base
directories (as we would when "unreleased-1.3" became "Debian-1.3"), a
lot of symbolic links would break.
Thus there are two good reasons why the distribution _name_ (be it rex
or bo or unreleased-1.3) shouldn't change. Because of that, it is good
to choose names that don't reflect the release status of the
distribution.
efraim@argh.org said:
> One question though: Why's hamm called hamm/hamm/ on the ftp archives?
> What for?
In addition to the main distributions (rex, hamm, bo) Debian has also
packaged programs which don't meet our free software guidelines. Those
are placed in the "non-free" and "contrib" directories, which is
outside of rex or bo.
When bo was nearing release, while rex was "stable", some people
complained that some of the non-free and contrib packages had
dependencies on things in unstable. This was threatening to force
people into using unstable when they wanted to remain in stable. So
with hamm, it was decided to move non-free and contrib under hamm (in
hamm/non-free and hamm/contrib) so that non-free packages that depended
on hamm main packages could be kept separate from non-free packages
that were safe to use with bo. what would have been the hamm main
distribution became hamm/hamm. Offhand, I don't know why it wasn't
hamm/main.
--
Buddha Buck bmbuck@acsu.buffalo.edu
"Just as the strength of the Internet is chaos, so the strength of our
liberty depends upon the chaos and cacaphony of the unfettered speech
the First Amendment protects." -- A.L.A. v. U.S. Dept. of Justice
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
debian-user-request@lists.debian.org .
Trouble? e-mail to templin@bucknell.edu .
Reply to: