Re: "Freezing" non-free and contrib
On Sat, 14 Dec 1996, Philippe Troin wrote:
> We should do this ASAP before rex and bo diverge too much. How about
> non-free-stable, contrib-stablem and non-free-devel, contrib-devel ?
A listing of the current debian-directory doesn't fit on my 80x25 screen
(in long mode). There must be something fundamentally wrong. ;-)
I'm really new on this mailinglist but I fear the issue of the directory
layout for the ftp-area has been discussed more than enough. But Philippe
has made up a valid point so I'm throwing my 2c in ... don't be afraid, I
am not interested in a religious war upon the issues below.
Save the internet - save bandwith
---------------------------------
Re-organizing the directory structure currently means a lot of network
load. Our goal should to prevent such waste of bandwidth in the future
(for the purpose of moving a file to another location it's deleted and
re-transmitted).
One solution to this problem could be a directory ".everypackage" that is
not visible to the user but contains all packages. The rest of our
directory tree would only hold links into ".everypackage". If we ever want
to re-organise the tree the changes would only fetch (via ftp) the
information about deleted and new links (which is small compared to the
whole package). It would be wise to set the permissions to --x--x--x to
prevent a directory listing (sloooow due to the huge number of files in
it).
As a side-effect, some mirrors (even master) would save disks space as
long as the development- and stable-version differ not to much. It would
be even possible to store both on a CD.
Yes, there must be some platform-dependent directories in ".everypackage"
to prevent naming conflicts but this is not in the way of the original
intention. (Furthermore, some sites may not have that much disk space in
one piece.) Example:
.everypackage
|-- free
| |-- alpha
| |-- common
| |-- i386
| |-- mk68k
| `-- sparc
|-- non-free (same as "free")
`-- unsupported (same as "free")
The seperate directories for non-free and unsupported guarantee easy
making of "free" CD-ROMs: just leave out the contents, the links in other
places can remain to document the avaiability of those packages.
Even more, the vendors could think about stripping the code from those
non-free packages and keep the description (is "dselect" able to handle
this gracefully, e.g. with a "non selectable" item or such?).
A new directory layout
----------------------
I suggest a very deep directory structure for the ftp-area but I think
it's ok if it enhances navigation in a way that everyone is able to find a
thing with 1 try.
Motivation for my wishes
- it's not clear what directory has what purpose (hey, there are
people who's native language isn't English and they even have more
problems guessing). Reducing the number of top-level directories
might help:
debian
|-= README
|-= README.mirrors
|-= README.non-US
|
|-- documentation
|-- dos-tools (or just "tools" with sub-directories "dos", "win", ...)
`-- releases
- using codenames for a release is fun but it is also confusing;
it's behind what the average beginner can understand and of
little use for the developers because we don't catch the
interim-releases as 1.1.11 and such. I would vote to drop codenames.
All releases should be hidden in a directory called "releases":
releases
|-- 1.1
|-- 1.2
`-- 1.3
|-- installation
|-- packages
`-- sources
Where "packages" consists of
packages
|-= Packages
|-- free
| |-- alpha
| |-- common
| |-- i386
| |-- mk68k
| `-- sparc
|-- non-free (same as "free")
`-- unsupported (same as "free")
This layout implements Phillipes wishes. Instead of "all" I
used "common". (Hey, it just looks like .everypackage ...)
Package classification
----------------------
And while we're at it, we could re-think the old "binary"-directory.
Currently it corresponds with "sections" in the packages-file resp.
"dselect".
Maybe it's a good idea to add a line "Filename:" to the Packages-database
that specifies the filename relative to ".everypackage". Another field
named "Releases:" specifies the releases of the debian distribution this
package belongs to (the links on the ftp-area could be automatically
generated using this information). Multiple release are allowed.
The current "Section:" should be supplemented by a subsection to
achieve a finer granularity when choosing packages with "dselect".
Example:
Section: mail->tools->filters (for "procmail")
Instead of "Section:" the term "Classification:" would fit better.
Alternative Classifications should be allowed.
-Winfried
--
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
Reply to: