[debpool] Re-evaluate the goal for debpool

[Free Ekanayaka]

|--==> Andres Mejia writes:

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

  AM> Did you mean Andrea or me (Andres)?

Sorry Andres, my finger fell mistakenly over the "a" key instead of
the "s", just beside it!

Free

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

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

  AM> Regards,
  AM> Andres

  AM> _______________________________________________
  AM> Debpool-devel mailing list
  AM> Debpool-devel at lists.alioth.debian.org
  AM> http://lists.alioth.debian.org/mailman/listinfo/debpool-devel