[debpool] Re-evaluate the goal for debpool

[Free Ekanayaka]

Hi Andrea,

sorry for having been silent till now. I've been using the SVN version
of debpool for while, and it worked ok, even if the support for
multi-arch uploads is not completely satisfactory (as far as I can
tell you can't, for instance, track different versions for different
archs).

As the project has starved for a while, I've decided to switch my
repository to reprepro, which I find very complete and stable. I don't
know if it can work for others too, but before spending time on
debpool I would try to compare them, and see what makes debpool
special and worth of further development.

|--==> Andres Mejia writes:

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

  AM> First question was about moving debpool from SVN to git.

No problem for me.

  AM> Second question was about uploading a new version of debpool.

I've used the SVN version for a while, it's better than the current
one in the pool.

  AM> Finally, the last question was about requesting comments from people
  AM> in other mailing lists (such as debian-mentors).

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

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

  AM> "to keep the requirements for packages not
  AM>   found in the Debian core system (Essential packages, or those with
  AM>   Priority required) to an absolute minimum (ideally, 'none'), or at the
  AM>   very least, only require packages that can easily be compiled on a system
  AM>   with little more than a shell, perl, and a working C compiler."

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

In this case the goal would be very similar to the features reprepro
offers.

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

In this sense debpool has some advantage with respect to reprepro,
because it's slightly easier to setup and less complex (but less
powerful also). However this could be improved by providing more
examples/docs for reprepro, and/or making it easier.

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

This another advantage of reprepro, it has very few depedences.

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

Dak is definitely overkill in most situations :)

Free