SlackwareThis Forum is for the discussion of Slackware Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
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.
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.
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.
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.
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.
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.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.