Joey Hess <[EMAIL PROTECTED]> writes:
> Lars Wirzenius wrote:
>> Frank Lichtenheld and others have brought up the idea of automatically
>> testing installation, upgrading, and removal of packages. It struck me
>> that it should be pretty simple to implement at least basic versions of
>> this. The result: http://liw.iki.fi/liw/download/piuparts-0.4.tar.gz
>>
>> I have attached the manual page.
>>
>> The current version is quite simplistic. It may well be too simplistic
>> to work for more than in simple cases, but it's a start.
>>
>> I'd be very curious to hear about suggestions for improvements.
>
> I want to run a test that installs each package in woody in turn,
> upgrades them to sarge, then to sid, then purges it, then looks for
> /usr/doc and /usr/info stuff that is were produced during the package's
> install or upgrade and not removed.
Good idea. Things like that should be collected for the etch Release
to cover all major changes that are release goals. Another thing would
be to check if anything links against an old C++ abi and so on.
A more general test would be to install/upgrade/purge a package and
then report any changes in the chroot.
>> If the package is known to apt-cache, piuparts also does an
>> upgrade
>> test, where it first installs the package with apt-get,
>> and then
>> installs from the package files given on the command line, and
>> finally
>> removes and purges everything that got installed. The
>> assumption is
>> that the version apt-get finds is older than the package
>> file. The
>> upgrade test is not performed if -a is used.
>
> I think this can not quite do it, since the chroot will need to be a
> woody chroot but get at least partially upgraded in each test to allow
> installation of the sarge and sid packages. It looks like piuparts is
> otherwise close to the tool I need.
Create a lvm logical volume of a clean chroot. Make a snapshot of it,
mount proc, do the test, kill (and probably report) any residual
processes, umopunt proc, kill snapshot.
Using lvm is the fastest way to do this. Alternatives are to copy or
untar a clean chroot for every test. But that needs more time.
MfG
Goswin
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
