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.

Introduction to Linux - A Hands on Guide

This guide was created as an overview of the Linux Operating System, geared toward new users as an exploration tour and getting started guide, with exercises at the end of each chapter.
For more advanced trainees it can be a desktop reference, and a collection of the base knowledge needed to proceed with system and network administration. This book contains many real life examples derived from the author's experience as a Linux system and network administrator, trainer and consultant. They hope these examples will help you to get a better understanding of the Linux system and that you feel encouraged to try out things on your own.

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.

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.

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 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.

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.