[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#200654: ITP: debpool -- pool-based DEB package archiver



On Thu, Jul 10, 2003 at 03:14:37PM -0400, Colin Walters wrote:
> On Wed, 2003-07-09 at 14:55, Joel Baker wrote:
> 
> > DebPool is a pool-based DEB 
> 
> s/DEB/Debian/ ?

Hmmm. I'd been hesitant to say it that way, but on reflection, I think
it's actually *more* accurate - since debpool will handle changes, dsc,
{orig.,}tar.gz, diff.gz, and deb.

> > package archiver designed with a goal of
> > removing any dependancy on code not shipped as part of the core Debian
> > system.
> 
> By "core" here do you mean priority >= standard?

Yes. Better ways of expression that in short form welcomed. In some
sene, it even goes beyond that; theoretically, right now you can run it
with a subset of the things that are required to build most packages
(coreutils, dpkg, perl, and a shell - no gcc required).

> > 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
> 
> How are you implementing this?  Do you have some sort of database about
> which packages are in which distributions?

Tied hashes, at the moment (because they come with perl's core setup).

> >  and avoiding external dependancies.
> 
> This seems like an unfortunate reason to write a whole new program.  If
> the problem is mini-dinstall's dependency on python-logging, I could
> probably suck it into the package.  In any case it'll be standard in
> Python 2.3 which is why I've been lazy about doing it.

The problem is that it's written in python, which build-depends on emacs,
which build-depends on.... eventually, you have something like a few dozen
packages to get working, before it will successfully run. I mentioned to
Joey Hess (who also raised this question) that there are more details in
the README.Why file, but this is targeted, in part, at solving the problem
I have as a porter wanting a self-hosting port.

mini-dinstall is capable, but hard to bootstrap to the point it can do it's
job; debarchiver is simple, but hard to patch and doesn't support a lot of
things.

Thus, the focus on making it run not only in a fresh install before any
other packages are put in, but on making it run with only the tools that
one more or less has to copy in from elsewhere to build *any* Debian
package.

Since both of the major questions have come on this set of topics, I'm
going to send a copy of the README.Why file to the bug, so that people can
see what it (currently) says.
-- 
Joel Baker <fenton@debian.org>

Attachment: pgpMPWy0FN3sy.pgp
Description: PGP signature


Reply to: