LinuxQuestions.org - pkgcheck.py: calling for beta testers

- Slackware (https://www.linuxquestions.org/questions/slackware-14/)

- - pkgcheck.py: calling for beta testers (https://www.linuxquestions.org/questions/slackware-14/pkgcheck-py-calling-for-beta-testers-356973/)

pkgcheck.py: calling for beta testers

Hi all,

I have started coding a Python program that does a sanity check on a Slackware package. I've tried to implement all the rules I have found both here and on linuxpackages.net, and I think I have coded them all except one which requires some more thought.

The objective was
- to check the packages I have created myself before sending them to linuxpackages
- to check packages I download before I install them.
I have only little experience in creating packages so this program is probably far from perfect, but I've tried it on a lot of packages and the results seem consistent to me.

I would appreciate if some of the more experienced people here could perhaps give it a try and could provide me with some feedback on errors or missing functions.

The program is available at http://www.homepages.lu/pu/pkgcheck.html and is only around 9500 bytes long. At this point, it's a simple Python executable without any documentation, but its usage is really straightforward.

Hoping for some feedback,

-pu

First of all, I would like to say this program was a very good idea.

I have been thinking of getting into submitting packages to LinuxPackages.net myself (just for my own personal use, I usually pump out 20 packages a week for various programs, so I might as well help other s out while I am at it) and have always been troubled by making sure my packages meet the rules for LP.net (even though I have gotten packages from there that did NOT meet their specified requirements, but that is another story).

Anyway, I have run it on a few of my packages, and so far it looks good.

It picked up the obvious things, like files installed to /usr/local, and no documentation included. I also like that I can easily see the contents of the package.

For some additions to the program, I would suggest:

1. An option to write the results to a file
2. A bit more organized output, for example put in some line breaks or horizontal lines, and perhaps give a summary for problems found, either by default, or make it an option. Something like:

Code:

Results

--------------------------------------------------

Objects in "local" directories:              23



File Checks

--------------------------------------------------

File                                        Status

--------------------------------------------------

install/slack-conflicts                  Missing!

install/slack-desc                        OK

install/slack-suggests                    Missing!

And so on.

Just make it a bit easier to read.

I'll check it out with a few other packages, see what I come up with.

Quote:

Originally posted by MS3FGX
1. An option to write the results to a file

What would this add in comparison to redirecting at the bash level?

Quote:

Originally posted by MS3FGX
2. A bit more organized output, for example put in some line breaks or horizontal lines, and perhaps give a summary for problems found, either by default, or make it an option.

Yes, I've been thinking about this, but I first concentrated on getting the checks done properly.
Likewise, I am not yet convinced on what I consider a simple information message, and what is considered to be a warning. I guess it even depends on the context.

Quote:

Originally posted by MS3FGX
I'll check it out with a few other packages, see what I come up with.

Thanks. I'll shortly add an option to check if binaries and libraries are stripped, that's one feature that is still missing.

Quote:

What would this add in comparison to redirecting at the bash level?

Nothing really, but it's a bit more userfriendly for the uninitiated.

But do you really want that? Some basics UNIX design rules:

- Silence is golden
- Save trees

(http://en.wikipedia.org/wiki/Unix_philosophy)

Userfriendly output is useless if you want to pipe the results to another program, which would be useful. In the end having just a bunch of \t and \n separated fields would be best, they are easily cut-able and awk-able.

A good reading on this subject is http://catb.org/~esr/writings/taoup/html/.

I have two questions in this context:

1 - What kind of program could parse the output of pkgcheck.py and do something useful? Usually, errors in packages have to be corrected at the SlackBuild level, and that can and should not be automatic (or does anyone have a SlackBuild generator?). So I guess the output is really destined at a person, not a program, and readability could be useful.

2 - Is it useful to run the script on a bunch of packages? Obviously I do that for testing, but in real life it would probably be done package by package. I cannot see any real use for statistics, either for identifying the most common errors or for identifying the most broken package in a lot.

What do you think?

Quote:

Originally posted by uselpa
A good reading on this subject is http://catb.org/~esr/writings/taoup/html/.

I have two questions in this context:

1 - What kind of program could parse the output of pkgcheck.py and do something useful? Usually, errors in packages have to be corrected at the SlackBuild level, and that can and should not be automatic (or does anyone have a SlackBuild generator?). So I guess the output is really destined at a person, not a program, and readability could be useful.

2 - Is it useful to run the script on a bunch of packages? Obviously I do that for testing, but in real life it would probably be done package by package. I cannot see any real use for statistics, either for identifying the most common errors or for identifying the most broken package in a lot.

What do you think?

At the moment you may be right, but Slack porting efforts are progressing rapidly. If you have to maintain packages over multiple platforms (e.g. within a company, or for a package repository), it is often useful to do bulk-builds, and a checking package script may be useful to (semi?-)automatically check bulk builds.

I've just put version 0.02 online. The main change is that the script will now also detect non-stripped binaries and libraries.

At this point, I have implemented all the checks that I have been able to find in the various documentation sources. Please feel free to post your suggestions if something is missing.

The official homepage with a proper package for installation and a start of documentation can now be found at http://www.homepages.lu/pu/pkgcheck.html.

link seems to be broken for me. :(

The first does no longer exist, the second is the new home (http://www.homepages.lu/pu/pkgcheck.html).