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:
/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
/pub/debian/package-pool/non-free/
d/i/stributed-net-pproxy/
distributed-net-pproxy_277b.orig.tar.gz
distributed-net-pproxy_277b-1.dsc
distributed-net-pproxy_277b-1.diff.gz
distributed-net-pproxy_280-1.orig.tar.gz
distributed-net-pproxy_280-1.dsc
distributed-net-pproxy_280-1.diff.gz
distributed-net-pproxy_277b-1_alpha.deb
distributed-net-pproxy_277b-1_i386.deb
distributed-net-pproxy_280-1_i386.deb
distributed-net-pproxy_280-1_sparc.deb
/pub/debian/package-pool/non-free/
f/o/obar/
foobar_1.1.orig.tar.gz
foobar_1.1-3.dsc
foobar_1.1-3.diff.gz
foobar_1.1-4.dsc
foobar_1.1-4.diff.gz
foobar_1.1-3_i386.deb
foobar_1.1-4_i386.deb
>
> 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:
/pub/debian/dists/slink/
main/
binary-alpha/
admin/
cruft_0.9.6.1.deb -> ../../../../../package-pool/
main/c/r/uft/cruft_0.9.6.1_alpha.deb
binary-i386/
admin/
cruft_0.9.6.deb -> ../../../../../package-pool/
main/c/r/uft/cruft_0.9.6_i386.deb
binary-m68k/
admin/
cruft_0.9.6.1.deb -> ../../../../../package-pool/
main/c/r/uft/cruft_0.9.6.1_m68k.deb
source/
admin/
cruft_0.9.6.tar.gz -> ../../../../../package-pool/
main/c/r/uft/cruft_0.9.6.tar.gz
cruft_0.9.6.dsc -> ../../../../../package-pool/
main/c/r/uft/cruft_0.9.6.dsc
cruft_0.9.6.1.tar.gz -> ../../../../../package-pool/
main/c/r/uft/cruft_0.9.6.1.tar.gz
cruft_0.9.6.1.dsc -> ../../../../../package-pool/
main/c/r/uft/cruft_0.9.6.1.dsc
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
(daily)
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
unstable.
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
there.
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:
foobar_1.2.3.orig.tar.gz
and
foobar_1.2.3.hurd.orig.tar.gz
Or if the upstream source is the same, make the hurd reference part of the
Debian version:
foobar_1.2.3-1.diff.gz
and
foobar_1.2.3-1.hurd.diff.gz
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: