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

Re: Sponsor Checklist



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.

Say I've just done a pbuilder run for a GUI package, it used some
packages from a previous build and updated those that needed updating -
maybe 20Mb all in. piuparts then ignores all that and starts
downloading the SAME binaries all over again!

I might look at apt-cacher but right now, I find it easier to simply
not use piuparts and do my own testing using pbuilder --login - it's
only a case of sudo cp pbuilder/result/foo*.deb /basetgz/foo in a fresh
chroot, parse some dpkg -I info to get the dependencies and then play
around with dpkg -i, dpkg -r, dpkg -P etc.etc.. Even if piuparts did
use /var/cache/apt/archives, I don't think I'd use it again. The output
is nonsensical, the process is unnecessarily complicated and the error
messages are completely unhelpful, IMHO. :-)

Maybe one day I'll write a sensible replacement for piuparts using the
pbuilder code - I've already got the basic script in emdebian-tools.
All that is actually needed is to use the existing pbuilder code to
unpack the existing basetgz, use the existing /var/cache/apt/archives
with a few updates if necessary (which is a one-liner in pbuilder) and
run a series of 'sudo chroot dpkg foo' commands. That way, it could
simply be tagged onto the end of a pdebuild run. At DebConf, Junichi
Uekawa said he was looking at a similar extension to pbuilder - along
the lines of --login-after-failed-build and it would be relatively
simple to create support for a test routine that cleans the chroot and
runs a series of dpkg tests directly after the build.

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?

Would you prefer to use an integrated pbuilder solution (if I get
around to it)?

-- 


Neil Williams
=============
http://www.data-freedom.org/
http://www.nosoftwarepatents.com/
http://www.linux.codehelp.co.uk/

Attachment: pgpwuS1hQM3Ms.pgp
Description: PGP signature


Reply to: