Re: Proposal: incremental release process (the package pool)

[Philip Hands <phil@hands.com>]

Joey Hess <joey@varesearch.com> writes:

> Can people who favor package pools come up with a list of things package
> pools give us that this much simpler approach doesn't?

I was under the impression that the package pools idea was orthogonal
to this (I could be missing the point, not having paying very close
attention to this re-hashing of the issue).

The package pools bit that I was in favour of consisted of:

  an area under which every package in every current (stable,
  unstable, testing etc.) distribution would be found.

  a directory naming convention that would place all the files for a
  package under a directory of its own.  This would probably have to
  be based on the name of the source files, so that multi-binary
  packages would be grouped together.  i.e.  for mgetty we'd have a
  directory called something like:

    package-pool/m/g/e/mgetty/

  that would contain a copy of all the package's files, something like:

    mgetty-docs_1.1.18-1_all.deb
    mgetty-docs_1.1.21-1_all.deb
    mgetty-fax_1.1.18-1_i386.deb
    mgetty-fax_1.1.21-1_i386.deb
    mgetty-fax_1.1.18-1_sparc.deb
    mgetty-fax_1.1.21-1_sparc.deb
    ...
    mgetty-viewfax_1.1.18-1_i386.deb
    mgetty-viewfax_1.1.21-1_i386.deb
    mgetty-viewfax_1.1.18-1_sparc.deb
    mgetty-viewfax_1.1.21-1_sparc.deb
    ...
    mgetty-voice_1.1.18-1_i386.deb
    mgetty-voice_1.1.21-1_i386.deb
    mgetty-voice_1.1.18-1_sparc.deb
    mgetty-voice_1.1.21-1_sparc.deb
    ...
    mgetty_1.1.18-1.diff.gz
    mgetty_1.1.18-1.dsc
    mgetty_1.1.18-1_i386.deb
    mgetty_1.1.18-1_i386.changes
    mgetty_1.1.18.orig.tar.gz
    mgetty_1.1.21-1.diff.gz
    mgetty_1.1.21-1.dsc
    mgetty_1.1.21-1_i386.changes
    mgetty_1.1.21-1_i386.deb
    mgetty_1.1.21-1_sparc.changes
    mgetty_1.1.21-1_sparc.deb
    mgetty_1.1.21.orig.tar.gz
    ...

When a package hits Incoming, it should be placed into it's
package-pool directory immediately, and should not be touched or
renamed until it is eventually deleted.

Distributions are then created by hard-linking (or perhaps
soft-linking, but this causes mirroring problems) the distribution
files (which should be arranged as they are now) to the package pool.

This way, a file will never be transfered to the mirrors more than
once, because it will have a constant name throughout it's life.
rsync can install and remove the links, with minimal fuss.

Old versions of files can be left around for a while after they get
replaced, so that reversing an upload becomes possible in the case of
serious bugs.

Note, I'm not suggesting that anyone attempt to point apt at the
package pool area, unless they were previously doing something like
pointing apt at Incoming.

If this isn't what ``package pools'' currently refers to, please come
up with a new term for this to keep things clear, rather than muddying
the waters any more than I just did.

Cheers, Phil.