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.
Great litle script!
I only have one question. Does it check if any required packages are already installed on the system?
Many thanks
You're welcome! No, it doesn't check if any required packages are on the system. That is not its job. It just creates queuefiles for sbopkg by parsing the REQUIRES= line in each .info file recursively. Basically, it just does what you would do manually if you looked at each REQUIRES= line and created an sbopkg queuefile by hand. It's then up to the user to view the resulting queuefile and make edits as necessary. For example, to pass options to the SlackBuild scripts. This is documented in sbopkg's queuefiles functionality.
When you load up the resulting queuefile in sbopkg then sbopkg will, just like with other queuefiles, mark what is already installed when you process the queue.
It might be a good idea to check for "%README%" in the REQUIRES line and just echo the packages in the generated queuefile that include it to the console at the end. I understand that one is expected to read the README of each package in the queue before building, but this might make it clear that certain packages require additional action. Or since this will probably be used in bulk, add comments in the queuefile with README packages. Just a thought.
While the idea of checking for %README% is a good one, it only works reliably if all maintainers add it to their info-files, when clarifications about optional dependencies (or other options) are mentioned in the README.
It might be a good idea to check for "%README%" in the REQUIRES line and just echo the packages in the generated queuefile that include it to the console at the end. I understand that one is expected to read the README of each package in the queue before building, but this might make it clear that certain packages require additional action. Or since this will probably be used in bulk, add comments in the queuefile with README packages. Just a thought.
Great idea. Just committed this to the script in SVN. Thanks!
I played a little with sqg using it with my repository:
- I've tried to modify it a little to use it when we have a git repo;
- I've deleted the setting of REPO_ROOT, REPO_NAME and REPO_BRANCH because they override the ones specified in /etc/sbopkg/sbopkg.conf (personal taste I think, really dunno if this is on purpose);
- doing the above, I had to remove the check for REPO_DIR because that happens before /etc/sbopkg/sbopkg.conf is sourced.
Hi, ponce - thanks for checking out the script! :-)
Quote:
I played a little with sqg using it with my repository:
- I've tried to modify it a little to use it when we have a git repo;
Nice. Thanks for this -- seems like a good addition but I have not yet carefully looked at the patch. I'll have to test it out.
Quote:
- I've deleted the setting of REPO_ROOT, REPO_NAME and REPO_BRANCH because they override the ones specified in /etc/sbopkg/sbopkg.conf (personal taste I think, really dunno if this is on purpose);
- doing the above, I had to remove the check for REPO_DIR because that happens before /etc/sbopkg/sbopkg.conf is sourced.
Yes, this was on purpose to allow the user to override sbopkg.conf in sqg without having to modify sbopkg.conf every time. I know the variables can be passed too, but I think it's helpful to be able to set them within sqg as well without having to touch sbopkg.conf. Perhaps we keep the REPO_ROOT stuff in there while adding the git functionality?
Thanks again for checking it out and offering some suggestions. We should definitely add the git part.
I just checked it: works fine and looks better than my attempt
about the REPO_* variables...
I understand the script it's meant to be edited before launching it so this is really of little importance, but I was pondering if by default can be better to use the /etc/sbopkg/sbopkg.conf values (and so just comment out the three REPO_* lines): that should be the repository the user launching the script should be using already and of which he most probably have a local copy.
I noticed this because because I launched it only uncommenting the QUEUEDIR line and ATM I don't have a /var/lib/sbopkg/SBo local directory.
Thanks, ponce. I'll merge these changes into the svn copy and take another look at the REPO_ variables issue. Thanks for testing and for your suggestions and input!
Slight tweak to the script to skip packages with an empty REQUIRES= line unless a new SKIP_EMPTY variable is uncommented. Probably makes no sense to create queuefiles for packages with no dependencies in most cases.
nice, here I was clearing after the ones where $(cat $i | wc -l)=1 but it's if they don't get created at all it's one step further
maybe they could be useful for an eventual queuefile parser that will rely on a complete *.sqf database, but I think such software doesn't exists yet...
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.