[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Sponsor Checklist

On Wed, 1 Aug 2007 09:28:07 +0100, Neil Williams <codehelp@debian.org> said: 

> On Tue, 31 Jul 2007 22:13:03 -0500
> Manoj Srivastava <srivasta@debian.org> wrote:

>> On Tue, 31 Jul 2007 17:53:49 +0100, Neil Williams
>> <codehelp@debian.org> said:
>> > I can never run piuparts - it just takes far too long over my
>> > crippled internet connection. Isn't there some way of getting
>> > piuparts to use the cached archives like pbuilder does? I already
>> > use the existing pbuilder chroot but downloading ALL dependencies
>> > EVERY TIME piuparts runs is completely useless to me.
>> I am not sure I follow.  You can stash the tarball for the chroot
>> (you need chroots for pbuilder anyway).  Then you just have piuparts
>> do a simple install-purge test.
>> piuparts ../foo_1.0-2_i386.deb

> At which point piuparts downloads all the dependencies of that package
> (which for a Gnome or KDE package get to several hundred Mb or more)
> instead of looking in /var/cache/apt/archives etc. as pbuilder does.

        Hmm. I generally use a local proxy (Apt::Acquire::HTTP::Proxy,
 or something), so I have never notice that -- since _something_ had to
 download the packages anyway for me to be able to build/test it.  I
 also use apt-proxy to keep a local partial mirror, which also uses
 squid, so I don't know whether it is squid or apt-proxy saving me the

> I do not think that piuparts should be considered as an "essential"
> part of a package testing process. I see no reason to require the use
> of piuparts in a sponsorship situation (but then I don't see that
> piuparts is actually something I need myself either). Using piuparts
> complicates a simple part of the normal process for no apparent
> reason.

> Why do you consider piuparts worth using?

        Because nothing else catches what piuparts catches. It helps me
 meet the policy directive  that purge should get rid of whatever the
 package installed -- and no more. It also tests upgrades -- and really,
 nothing else does that.

        I do think that smoother upgrades is something debian needs to
 be providing; we already are pretty good at that, so ensuring we take
 steps to make it remain this way is a good idea.

"I'll rob that rich person and give it to some poor deserving slob. That
will *prove* I'm Robin Hood."-- Daffy Duck, Looney Tunes, _Robin Hood
Manoj Srivastava <srivasta@debian.org> <http://www.debian.org/~srivasta/>
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C

Reply to: