In the hopes that it will be illuminating, I have attached a copy of the README.Why file from my working copy of debpool. -- Joel Baker <fenton@debian.org>
Why have yet another Debian package repository tool? * Most or all of the other tools require extensive non-core support. While many users may not find this problematic, those working on a new port, and trying to make it self-hosting, will often have a difficult time trying to get some of the more packages with a complex tree of Build-Dependancies (such as Python) to a point where they can be compiled. Conversely, a working shell, an installation of Perl, and a compiler are some of the first things that must be present, simply because so much of the rest of the system depends on these (and they are often available from another port or a non-Debian system). Therefore, I have attempted to keep the requirements for packages not found in the Debian core system (Essential packages, or those with Priority required) to an absolute minimum (ideally, 'none'), or at the very least, only require packages that can easily be compiled on a system with little more than a shell, perl, and a working C compiler. Note that some amount of significant functionality (such as Release files and signature checking) does depend on more complex packages (such as GnuPG or the perl Digest modules), which is why these are in the Recommends field; however, these functions that use these are niceties (if very useful ones), and an archive can operate without them, if necessary. * No other tool handles the new pool-style layout readily. As of this writing, none of the tools in Debian except for katie (part of the softare used to run the primary Debian archives) can handle a pool-style directory layout in any straightforward fashion, while setting up a full instance of katie requires significant support infrastructure (such as an SQL server, among other things).
Attachment:
pgpap4qqcRElE.pgp
Description: PGP signature