[debpool] Re-evaluate the goal for debpool

[Andres Mejia]

Hello,

Before I start discussing the topic of re-evaluating the goal for
debpool, I want to bring up some questions I've asked in earlier posts
to this list. I'll summarize them.

First question was about moving debpool from SVN to git.
Second question was about uploading a new version of debpool.
Finally, the last question was about requesting comments from people
in other mailing lists (such as debian-mentors).

I wanted to bring them up as I've only received one response for the
issue with moving debpool from SVN to git. I think these other topics
would have to be addressed before we can even think about looking into
the next topic I'm bringing up.

The next topic I want to bring up is this. The goal that the original
author wanted for debpool was to allow porters of Debian to new
architectures and/or kernels the ability to keep their own self
hosting repository. This is the reason why in the README.Why it's
stated and I qoute:

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

I'm suggesting that we re-evaluate the goal for debpool to allow the
ability for both Debian and non-Debian based distros the ability to
setup and maintain their own Debian repository.

The reason for this is so that upstream developers of software
currently not found in Debian or unable to distribute their programs
in its current state in Debian can setup their own repository of their
packages and dependencies. Another reason for this is that In some
cases, upstream developers don't have a means to host their repository
to the public on a Debian based system. In other words, their web
hosting machines are using a non-Debian based distro.

In order to achieve this goal and at the same time continuing to
pursue the goal of the original author, the requirements for debpool
will have to change. Essentially, debpool would have to depend solely
on Perl, other Perl modules, and a small amount of programs that are
known to exist on a common Unix system and are easily compiled using a
working C compiler. This would mean that debpool would have to stop
relying on Debian specific programs (such as dpkg). Ideally, debpool
should only depend on Perl, but it would probably be alright to use
other Perl modules, as long as they rely only on Perl and/or a working
C compiler. Compress::Zlib wasn't a Perl core module until the recent
release of Perl (5.10), thus the reason I'm suggesting it's probably
alright to use other Perl modules.

If this can be done, this will have all the benefits I've described
earlier. This will also have the benefit of keeping debpool as a
lightweight tool in maintaining a pool based repository, as opposed to
the Dak.

-- 
Regards,
Andres Mejia