What next? [Was: Re: LiveCD or No LiveCD?]

Alexander E. Patrakov patrakov at gmail.com
Wed Feb 27 19:45:08 PST 2008

Hendrik Hoeth пишет:
> Thus spake Alexander E. Patrakov (patrakov at gmail.com):
>> If you want to help, here is a conceptually simple, but long and
>> boring task for you. Draw a tree of dependencies between packages on
>> the current full CD in dia or anything else that can be easily
>> converted to SVG.
> As a matter of fact this actually doesn't sound so frightening to me at
> all, since for a fair fraction of the packages I have a working
> serialized dependency order and notes anyhow. Namely for those packages
> which I'm using on my own systems.
> But ... what do you actually want? I ask this in terms of aims and
> purposes, not in terms of tasks, as I don't understand your reasoning in
> creating a graphic (and this even in a specific format).

The aim is to put this on a web page, in order to document why each package is 
on the current CD (and to see what's missing from the new CD, and, in the case 
anything is removed, what's left around as cruft).

>> For each leaf package that you know how to use, write a short document
>> (or a long document, if a package is not simple) explaining how to
>> test its basic functionality ("make check" alone doesn't count)
> Does "'make check' and look at the output, it should read XXX" count?
> What's "basic functionality" of a package?

Some minimal functionality without which the package is broken beyond repair. 
E.g., an audio decoder should be able to decode audio files, and a text editor 
should be able to open, edit, and save files (preferrably, without damaging 
UTF-8 characters).

Builtin testsuites don't count because they often test for packaging errors 
only. Take, e.g., cpio: a previous version didn't pack symlinks correctly (and 
this affected initramfs creation), and a testcase for this old bug is still not 
in the testsuite! Of course, if you have actually looked at the tests and 
verified that they go beyond the "program --version doesn't crash" testcase, you 
are welcome to refer to the testsuite, provided that you mention that this is a 
real testsuite and quote one of the tests.

> Taking libpng as an example.

Bad example: I asked for testcases only for leaf nodes, while there are programs 
that depend on libpng and are included on the CD. For non-leaf nodes, the 
functionality is tested by their dependencies, and your "compile and link a 
trivial program that calls png_read_png()" testcase is not needed because there 
are non-trivial programs down the road that do so.

>> You may assume that the test will be run in an emulator such as QEMU,
>> KVM or VMware, so instructions to fill the hard disk(s) with arbitrary
>> contents are allowed.
> This really sounds a bit like "please create exhaustive test cases for
> our 240 packages".

It is exactly that, without the word "exhaustive". The intention is, again, to 
put this on the web and thus to make it easy for a new developer to upgrade 
packages that he would otherwise not touch (e.g., looking at the bottom line of 
http://wiki.linuxfromscratch.org/blfs/wiki/InputMethods, you can test whether 
Anthy and SCIM work correctly after you upgrade them).

> Hints web page: 2007-08-28
> svn trunk/doc/: 2007-11-28
> I wouldn't have made that comment if they were the same.

Thanks for the notification. Indeed, one important difference has not propagated 
to the hints project, although I thought it did.

Alexander E. Patrakov

More information about the lfs-dev mailing list