[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Archive Restructuring - Package Pool

On Wed, Jul 29, 1998 at 02:03:54PM +0100, Philip Hands wrote:
> > 1. Structure of the Package Pool
> > --------------------------------
> > The directory hierarchy should be as follows:

> I think this is a mistake.  We will get this structure from the dists 
> in which a package is included, so why not take advantage of the fact 
> that we have two layouts, and arrange them differently.

My main concerns with different layouts was that it might make life
harder for mirrors to mirror just one architecture, or, more likely,
to exclude non-us or non-free.

I'm quite happy to change this internal structure to anything that is
convenient for mirroring purposes -- and if a flat hierarchy doesn't
cause difficulties, then that seems like a good thing, especially for
licensing concerns.

> /pub/debian/package-pool/main/
> 	c/r/uft/       [or some other approach to keep directories small]
> 		cruft_0.9.6.tar.gz
> 		cruft_0.9.6.dsc
> 		cruft_0.9.6.1.tar.gz
> 		cruft_0.9.6.1.dsc
> 		cruft_0.9.6.1_alpha.deb
> 		cruft_0.9.6_i386.deb
> 		cruft_0.9.6.1_m68k.deb

I've written a quick little script to produce a package pool based on
this layout, with the hamm, slink & sid distributions.

BTW, there don't seem to be *any* hamm sources for either cgiemail (m68k)
or r-mlbench/r-cran-nonfree (i386).

It's about 14MB of symlinks and stuff, and would be about 3GB if it
were a real package pool with no symlinks (according to du -sL).

The largest subdirectory is x/f/ree86, at just under 100 files, next
is l/i, with all the libraries it contains (68), followed by egcs,
python, and so on.

A problem did crop up, in that there are a fair number of packages with
only two letters in their name, including ae, bc, db, ee, gs, gv, m4, mc,
rc, xv and heaps others. Thirty-four in all. There weren't any with just
one character in it's name.

At the moment I'm just dumping them in "package-pool/a/e/ae*.deb" and
so on. A possible solution would be "package-pool/a/e/_/ae*.deb", but
for a simple hack, that was a pain.

Otherwise, that layout seems quite okay.

For those who are interested, the test pool is in ~ajt/archive/ on
master. The script used to create it is ~ajt/archive/package-pool/script.
It should work `anywhere', given appropriate modifications to the
variables at the top, and a local debian mirror, but I wouldn't bet on
it too heavily. Don't run it as root, or with an account that can modify
the mirror. It creates a package-pool of symlinks to the mirror in the
current directory.

> > 2. The disks/ directory
> > -----------------------
> I'm not sure why this should be in the package pool.  It doesn't seem to fit.
> Although I suppose that means that everything is available from there.

With the above layout, it doesn't fit too well, no.

The intention was that old versions of "stuff" in general (whether that
stuff be packages, sources, or disk images) should be kept out of the
main hierarchy, so people wouldn't have any cause to wonder "Ummm, there's
version 1.2, 1.3, 1.3.1 and 1.4 here. Which one do I choose? Are the new
ones buggy or something?  Maybe I should choose an older one... Hmmm...".

> Would this also mean that we should keep things like all verions of top level 
> README files somewhere in the package pool too ?

Do old versions of README files include any useful functionality that
might help out someone doing an install or upgrade, for which the current
version doesn't work?

That was, at least, the criteria by which it seemed worthwhile to keep
old packages and disk images.

> As an additional note, the directory used to store a package's files 
> should be based on the source package's name, so that binary packages 
> that end up with different names still get kept with their source.

(this is incorporated in the trial pool mentioned above)

> Making the selection of the destination directory in the package pool 
> totally mechanical, means that the Incoming --> package pool step could 
> be very simple (i.e. check the PGP sig, and do it), and automatic 
> (every 10 minutes ?)

This would be a Good Thing, if possible. IMHO.
> > 6. Miscellaenous Considerations
> > -------------------------------
> While the non-us area handles this problem, I'd prefer to see a general 
> purpose method for handling the exclusion of packages.  For example, violent 
> games are often illegal in Germany, and encryption is illegal in France, but 
> some of the non-US patent issues do not apply, so there is another subset 
> there.

I would also.

There would need to be some mechanism of people familiar with each
country's laws saying which packages aren't appropriate for whom --
I had no idea, for example, of Germany's laws above, so if I were to
package a violent game, wouldn't have considered the above. Coping
with just non-us isn't too onerous, but trying to consider every law
on the planet seems likely to be a touch harder.

So you'll forgive me if I don't try to incorporate a complete solution
to the above into the current proposal. :)


Anthony Towns <aj@humbug.org.au> <http://azure.humbug.org.au/~aj/>
I don't speak for anyone save myself. PGP encrypted mail preferred.

Remember to breathe.

Attachment: pgp2KsCYYwn2w.pgp
Description: PGP signature

Reply to: