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:
pgpMyvJ_bJIBt.pgp
Description: PGP signature