Re: Package Pool Proposal
On 21 Nov 1999, Guy Maor wrote:
> I am going to implement something like this.
>
> The archive will look like this:
> debian/dists/pool/{binary-arch,source}/x/package
> x is the first letter of the filename. Note that packages are not
> organized according to section in the archive, just filename.
Might it be better to use more granularity? This could lead to alot of files
in a dir, and we all know how debbugs handles that. Reiserfs handles that,
but it isn't part of a standard kernel, and we don't want to depend on
particular features of a filesystem, when we can design it right to begin
with.
> debian/dists/{stable,unstable,non-free}/binary-arch/Packages.gz
> debian/dists/{stable,unstable,non-free}/binary-arch/pool ->
Sure you mean debian/dists/{stable,unstable,frozen,foo}/
{main,contrib,non-free,data}/binary-*/...
> ../../../pool/binary-arch
> (similar for source tree)
> There are neither packages nor symlinks to packages here. The index
> refers to all packages through the pool symlink.
Sounds good.
> A database exists that records for each package:
> - what versions are available.
> - what version (if any) are in each distribution (stable, unstable, frozen).
> - what the sections and priorities are.
> - maintainer overrides.
> - when and by whom the package was uploaded.
> - changes file for the upload
> - rest of package and dsc info.
> - any piece of data I can think of that somebody might need
> when creating a distribution
Flat file? dbm? sql? ldap? This raw database could be made available for
download, so then each system could choose how it wants to add its own pkgs.
Almost like dynamic packages.gz
> The Packages.gz and Sources.gz are built from this database alone.
> The database is editable from a web-page by maintainers/ftpmasters
> (not every field by everybody of course). All changes to the archive
> are made through the database. The change is then reflected in the
> next day's archive run.
So you mean dinstall would process incoming more often than once a day, but
the packages.gz would only be updated once a day? This could lead(possibly)
to faster turn around times in the bts as well.
For this bts feature, we might need a new state, tho. 'Fixed, but not
accepted yet(1).'
> Creating a new distribution requires writing code which answers the
> question, given the available versions of this package, which one to
> choose? For example, an unstable-but-no-nmus distribution could pick
> the latest, maintainer-uploaded version. A mondays-suck distribution
> could ignore anything uploaded on Monday. Those are silly examples,
> but they demonstrate a powerful concept.
This could be used for all those people wanting to become developers, but who
can't because NM has been closed. They could upload into this pool, and we
could have a separate distribution for them.
> Mirroring by architecture and by freeness is still possible, but
> mirroring by distribution is not possible without a specialized tool.
> I think the lack of ugly symlink trees is worth it though. Mirroring
> a single distribution is not that simple today; you have to be careful
> about which symlinks to follow and which to not.
Actually, mirroring by arch now isn't all that easy. You have to manually
specify the distributions, then the arch. It would almost be nice if the
higher dir was arch, then dist. But that is an implementation detail.
> There will be some transition plan of course so that mirrors are not
> overly burdened.
Rsync can handle hardlinks, and I think most top level mirrors(the ones that
pull from master) use rsync.
> As you can see there are some details yet to be worked out, but that's
> the basic concept.
Back at ALS(Atlanta Linux Showcase) the debian developers talked about
reworking and rewriting dinstall, for new features, cvs-like edittability,
package pools, faster run times, etc. I recently created a list,
debian-archivetool@novare.net(2). Maybe we could get a
debian-archivetool@lists.debian.org created. The list @novare has had no
traffic.
> Awaiting comments,
> Guy
It is great to see you in action again!
>
>
> --
> To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
>
>
----BEGIN GEEK CODE BLOCK----
Version: 3.12
GCS d- s: a-- c+++ UL++++ P+ L++++ !E W+ M o+ K- W--- !O M- !V PS--
PE++ Y+ PGP++ t* 5++ X+ tv b+ D++ G e h*! !r z?
-----END GEEK CODE BLOCK-----
----BEGIN PGP INFO----
Adam Heath <doogie@debian.org> Finger Print | KeyID
67 01 42 93 CA 37 FB 1E 63 C9 80 1D 08 CF 84 0A | DE656B05 PGP
AD46 C888 F587 F8A3 A6DA 3261 8A2C 7DC2 8BD4 A489 | 8BD4A489 GPG
-----END PGP INFO-----
1: http://benham.net/pipermail/debbugs/1999-November/000051.html
Reply to: