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. :) Cheers, aj -- 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:
pgpdgghf185qN.pgp
Description: PGP signature