(This may be better on the debian-pool list, I guess)
On Wed, Aug 23, 2000 at 03:26:51PM +1000, Drake Diedrich wrote:
> pinstall (part of the packagepool at http://master.debian.org/~dld/pool/
> ) does the signature check and initial install into the pool database. The
> location within the pool archive is currently simply pool/sourcename . The
> pool itself can handle any hash though,
The structure Jason and I have been discussing is slightly different,
and has some really nice properties. The archive layout would be
something like:
pool/main/libf/libfoo/libfoo-dev_1.2-1_i386.deb
That is:
* separate pools for each component (main, contrib, and non-free,
and presumably non-US/main, non-US/contrib, and non-US/non-free
also)
* binaries included based on the source package name
* hashing based on either the first character of the source
package, or the first four characters, if it's a library source
(to keep it fairly evenly distributed)
This means to find a package you need to know five things:
its name
the version you want
the architecture you want it for
the name of its source package
the component its in
It also means it's trivial to not mirror non-free if you want.
Now, while the actual pool layout separates components at the top level,
the database *doesn't* do this, at least the way we've been talking about
on IRC. Instead, we have (in relational speak) a single huge table that
basically says:
[ binary_name, binary_version, architecture, source, component, ... ]
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
(translating, that is that given a binary package, its version and its
architecture (ie, the filename libfoo-dev_1.2-3_i386.deb), we can uniquely
determine the source, component, and any other applicable details)
This means we *won't* permit more than one of, eg:
pool/main/libf/libfoo/libfoo-doc_1.2-3_all.deb
pool/main/libf/libfoo-hurd/libfoo-doc_1.2-3_all.deb
pool/non-free/libf/libfoo/libfoo-doc_1.2-3_all.deb
It also means that when we decide which packages are in which
distribution, we don't need to separate by component. So to specify
packages in potato, say, we can simply have a table:
potato, fileutils, 4.0l-8, alpha
potato, fileutils, 4.0l-8, arm
potato, fileutils, 4.0l-8, i386
potato, xv, 3.10a-25, alpha
potato, xv, 3.10a-24, arm
potato, xv, 3.10a-35, i386
(this would be done differently in LDAP. The relational way seems clearer
for this purpose though, IMO)
> [...]
> non-free/contrib under the current model would have to be separate upload
> queues and archives, possibly running on the same server and physically
> overlapped though. It wouldn't be terribly difficult to add special casing
> for non-free or contrib sections, but it's a little unclean to have the
> install tool making policy decisions like that IMO.
It's probably suboptimal to have to have separate incoming queues.
The above layout basically just means you have to construct a new
"Component:" field for the all-packages-in-the-pool table.
This isn't entirely straight forward to extract at present, it either comes
from the .changes file, as in an upload to:
mosaic (2.7b5-8.1) non-free; urgency=low
or an upload to:
distributed-net-pproxy (277b-1) unstable; urgency=low
with Section: non-free/misc
In any event, it's not *making* policy decisions, it's simply enforcing
them. I'm inclined to think having a separate "Component:" field in the
source control stanza would be a better way of expressing it.
If experimental .debs are to be included in the pool, the above would
probably imply we'd end up with:
dists/experimental/{main,contrib,non-free}
which probably isn't a bad thing.
Cheers,
aj
--
Anthony Towns <aj@humbug.org.au> <http://azure.humbug.org.au/~aj/>
I don't speak for anyone save myself. GPG signed mail preferred.
``We reject: kings, presidents, and voting.
We believe in: rough consensus and working code.''
-- Dave Clark
Attachment:
pgpXLzGZ4WCVJ.pgp
Description: PGP signature