[debpool] Re-evaluate the goal for debpool

[Andres Mejia]

On Monday 28 January 2008 4:59:49 am Free Ekanayaka wrote:
> Hi Andrea,

Did you mean Andrea or me (Andres)?
>
> 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

I'll give reprepro a try some time. It does seem debpool is dead, but I'll 
think it over before giving up on it.

Regards,
Andres