On Wed, Jul 09, 2003 at 03:54:09PM -0400, Joey Hess wrote:
> Joel Baker wrote:
> > DebPool is a pool-based DEB package archiver designed with a goal of
> > removing any dependancy on code not shipped as part of the core Debian
> > system.
> >
> > It is capable of all of the following:
> > * Tracking multiple distributions (however, it does *not* include
> > unstable -> testing promotion scripts).
> > * Generating Release files (requires libdigest-{md5,sha1}-perl)
> > * Verifying package signatures (requires gnupg).
> > * Signing release files (requires Release files and gnupg).
> > * Running in single-pass or daemon modes.
> >
> > DebPool is intended to be a lightweight replacement for the full Debian
> > archival scripts, in the tradition of debarchive and mini-dinstall, but
> > using a pool layout and avoiding external dependancies.
>
> If you have so many files in the archive that you need a whole hashed
> directory tree to hold them (pool, right?), why do external deps matter?
> Surely the extra disk space would be negligible.
In this particular case, which I document better in the README.Why file
I intend to put in the package, it is because I have exactly the
situation. It's not *common*, but no tool currently handles it at all
well.
'The situation' being a new port which is bootstrapping from the ground up
('netbsd-i386', in my case). I currently have hundreds of packages in the
archive, many of them rolling through as I try to track unstable and update
core things every week or two (when stuff is going well), and intend to
have an autobuilder in the relatively near future - but I have not yet been
able to untangle the dependancy tree of mini-dinstall (python Build-Depends
on Emacs, and let me tell you how fun THAT is to try to get working on a
new port...), and debarchiver is, frankly, just not up to the task (though
it's what I've been using, to date).
It isn't about disk space, but about the design view that requiring
heavy-weight, non-trivial packages outside the Debian core is not always
a good thing. Right now, it should, in theory, run with little more than
dpkg, perl, bash, and coreutils installed - less than it takes to build
most packages on a new port.
> Sometimes I wish we could have one thing that worked well, instead of 4
> that work kinda ok. In this case, I would like to have Release file
> generation and package signatures[1], but I also want a flat structure
> and would prefer to see these features added to something that already
> works.
Agreed. I strongly considered the alternatives before doing this; I
even talked to Ola about debarchiver and pools, but the wishlist bug has
been open for a long while, now, and every time I look at the code to
try to patch in the capability for pools, I start twitching.
That's completely aside from the question of Release files or signatures
(which mini-dinstall does just fine, AFAIK, but as noted above, it's
impossible to build enough infrastructure to run it until a long way
into the porting process). To me, being able to self-host an archive for
a new port is a big deal, especially given the (perfectly rational and
reasonable) attitude of ftpmaster thta they want to see some fairly large
amount of porting done *before* they consider putting in a new area in the
main archive.
> NIH?
Perhaps, but I've tried to avoid it. If there is, in fact, something which
requires few non-core packages, and does pools, I'd consider it even if
Release files had to be generated by a secondary script; that isn't that
hard to do.
--
Joel Baker <[EMAIL PROTECTED]>
pgpAQBmC3YeA7.pgp
Description: PGP signature
