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

Re: Archive Restructuring - Package Pool

> The Package Pool
> ================
> 0. Introduction
> ---------------
> A new directory should be created in the /pub/debian hierarchy:
> package-pool.
> This directory should contain the physical copies of (not symlinks to)
> all the packages currently distributed by the Debian group.
> 1. Structure of the Package Pool
> --------------------------------
> The directory hierarchy should be as follows:
> 	/pub/debian/package-pool
> 		main/
> 		contrib/
> 		non-free/
> 		non-us/			-- where applicable
> 		disks/
> [please see below for further explanation of the "where applicable"
> rider]
> Within each of package-pool/{main,contrib,non-free,non-us} should be a
> structure of the following form:
> 	  /pub/debian/package-pool/main/
> 		source/
> 			admin/
> 			base/
> 			...
> 		binary-all/
> 			admin/
> 			base/
> 			...
> 		binary-alpha/
> 			admin/
> 			base/
> 			...
> 		binary-i386/
> 			...
> 		...

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.

I think the main/contrib/non-* etc directories should be logically flat (even 
if they are actually split into sub directories for optimisation purposes)

Where the directories are split, I think it would be good to have all the
files for all the versions of a particular package in the same directory.

I also think that all information about what a file is, should be present in 
its filename, so an i386 package should contain i386 in the filename, rather 
than reflecting this in the directory that it is in.  This way is is 
immediately apparent what the file is, even if it is downloaded without the 
matching directory structure.

So to use your examples, we'd have:

	c/r/uft/       [or some other approach to keep directories small]
> Option 2: Release foobar_1.1-3 for both hamm and bo, compiling two
> separate packages, foobar_1.1-3_bo.deb (libc5 based) and

That's not the way we do this --- you need to make sure that the ``bo'' 
version sorts lower, so if the last bo version was 1.1-1, then a reasonable bo 
security fix would be 1.1-1bo3 if the hamm version were -3

So you'd end up with packages:

               foobar_1.1-3_i386.deb               (libc6)
               foobar_1.1-1bo3_i386.deb            (libc5)

> 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.

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

> 3. Changes to the dists/ hierarchy
> ----------------------------------
> Having thus found a nice place to dump all out packages, we can thus
> alter the current policy of having the distributions contain either a
> copy of the package itself or a symlink to a copy of the package in a
> previous release (*breath*), to just including a symlink to the
> package in the package-pool.
Continuing the first of the three examples above, we would thus have:

	                cruft_0.9.6.1.deb -> ../../../../../package-pool/
	                cruft_0.9.6.deb -> ../../../../../package-pool/
 	                cruft_0.9.6.1.deb -> ../../../../../package-pool/
 	                cruft_0.9.6.tar.gz -> ../../../../../package-pool/
 	                cruft_0.9.6.dsc -> ../../../../../package-pool/
 	                cruft_0.9.6.1.tar.gz -> ../../../../../package-pool/
 	                cruft_0.9.6.1.dsc -> ../../../../../package-pool/

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.

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 ?)

The act of symlinking the files into the unstable tree could be made dependent 
upon the files in the package pool passing some automated tests (i.e. lintian 
etc), and so once a new package is set up, should generally be automatic 

The act of linking them into the ``rolling-stable'' tree would be dependent 
upon them not having any important bugs against them after a certain time in 

Then they get into the frozen and stable trees by surviving a fairly normal
free/test regime.

> 6. Miscellaenous Considerations
> -------------------------------
> 6.1 Coping with non-us
> ----------------------

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 

Since the distributions are just going to be populated with symlinks, 
duplicating the whole lot, with a few packages missing, is something that 
would be fairly easy on a master site.

Mirrors could then choose the tree they wish to mirror.

> 6.3 The Package Pool and GNU/HURD
> ---------------------------------
> We do have a possible problem, however, with a single package-pool like
> this. In particular, what do we do with HURD packages?
> If we can build all our HURD packages from the same source as our GNU/Linux
> packages, we're fine -- the HURD release is no different to the alpha or
> i386 releases.
> If, however, we decide we would prefer to keep the sources separate (to
> reflect the different filesystem layout, different standard base system
> or something else) then the HURD does not fit into the above layout --
> at a minimum there would need to be two source directories.
> There are two possible options here: one is to say "To heck with it, we're
> talking about Debian GNU/Linux, Debian GNU/HURD should be *completely*
> separate, in /pub/debian-hurd, say."

I think for the packages which can be handled with an ``if HURD'' section in 
the debian/rules file, this should be done.

In the cases where this would not work, a hurd branch could be given a version 
number that includes a reference to hurd:


Or if the upstream source is the same, make the hurd reference part of the 
Debian version:


That way, if it becomes possible to merge the two trees, they will just drop 
the ``hurd'' from the version number.

> 6.4 License Changes
> -------------------

This seems to justify the idea that we should forget the main/contrib/non-free/
non-us separation.  If we do this (which seems like a good idea), we should 
still provide an indication that a set of files are non-free from within the 
package pool.

One way of doing that, would be to have the override file for a particular
package, in the directory that contains it in the package pool.  The overrides 
file needs to be able to have different settings for different versions of the 
same file, so we might have a file in the package-pool/f/o/o/bar/ directory 
containing something like this:

  foobar (<=1.0.0)   optional        non-free/devel
  foobar (>1.0.0)    optional        main/devel

> Any resolution requires, at a minimum, removing the categorisation of
> the package-pool, and having a single tree for main, contrib, non-free,
> and non-us, with packages from the different categorisations sitting
> side by side, in some sort of liberated harmony.
> We could still ensure that only the appropriate packages were put in
> the appropriate areas with moderately complicated scripting (if you're
> a US mirror, download this list of files, the download all the files in
> that list *and nothing else*!!), which could be made to work acceptably
> (especially with a US and a non-us master mirror.

we could add an optional exclusion flag to the override file, so if we assume 
that the foobar package contains cryptography:

  foobar (<=1.0.0)   optional        non-free/devel   usa,france
  foobar (>1.0.0)    optional        main/devel       usa,france

or if the foobar package got split into foobar and foobar-crypt binary 
packages, you might get:

  foobar (<=1.0.0)   optional        main/devel   usa,france
  foobar (>1.0.0)    optional        main/devel
  foobar-crypt       optional        main/devel   usa,france

Then the linkage into the trees could be duplicated for any number of target 
trees, with some packages being excluded from each.

How you decide what to do with the source in this case, I don't know ;-)

Cheers, Phil.

To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Reply to: