Subversion Repositories

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).