[ANNOUNCE] SBo/Sbopkg comprehensive queue archive
 

Hello everybody,

I'd like to share with the community the availability of a comprehensive queue repository for SBo/Sbopkg, including a queue file for each and every SBo package for Slackware 13.0. My hope is that it will help reducing the amount of time required to sort out the packages' build order.

Project repository:
http://gitorious.org/sbopkg-slackware-queues
Full announcement:
http://sbopkg.org/pipermail/sbopkg-u...ry/000440.html

I'm looking forward to hear comments, suggestions and of course problem reports.

With best regards
--
Mauro Giachero

Thanks, i dont use sbopkg so i cant comment on the content, but its queues seem very useful.

Any reason you dont submit them to the project?
Also did you use a script to generate them?
That might be more worth sharing :)

"Also did you use a script to generate them?
That might be more worth sharing"

+1

thanx Mauro, that sure was a lot of work, I've seen you're on it from last september :)

and thanx also for putting them on git, so one can track your repository branching his changes ;)

I found the script in the download. Thanks.

Thanks. That's a very useful idea.

Thank you - had *thought* about this previously; glad to see one of us has some initiative....

Thanks a lot, your work is highly appreciated!

Thanks to everybody for the nice words!

I assume "the project" is sbopkg. Well, I feel it's just too much stuff.

Actually, last September is when I rebuilt the repository, the work started earlier...

For the scripts, the interested folks can find them in the scripts directory. I usually do:
- sync with sbopkg
- ./gen-updates.sh
- kate *.sqf (manual queue review)
- ./cleanup-comments.sh
- mv *.sqf ..
- ./sanity-check.sh
- remove backups (*~ files) and commit.

I should also refresh the contents of the doc directory. Oh, well...

If SBo would unify the form of specifying dependencies, your work will be easier. However, I think this proposal will never get accepted.

Actually, the thing works reasonably well even without a specific agreement. The greatest hassle are READMEs telling things like "This is a dependency for foo", since they cause the generation of false dependencies.

Should the lists of the packages in the queue files be in the proper order for building the entire queue without interruption? For example, the Inkscape queue has pangomm listed after gtkmm, yet gtkmm depends upon pangomm. Though things may work regardless of the order built (i.e., it is not a build dependency), the program does halt and prompts the user whether or not to continue.

Good question. The answer is no, it shouldn't.

If you look at the queues, you'll notice that all dependencies refer to other queues, not to single packages. In your example, the inkscape queue is

(notice the '@' characters before package names, that trigger queue loadings). When parsing this, sbopkg will load the queues in order and, finding '@gtkmm', will load this:

that builds pangomm. The '@pangomm' in the inkscape queue then turns out being ignored by sbopkg.

The rationale is that every package/queue should list its dependencies only, not the dependencies' dependencies.

I've been thinking about writing a script that "simplifies" the queues by removing unneeded dependency specifications, like the pangomm one in the inkscape queue. I wonder whether this would be a good idea though.

I just wanted to throw in a "Thanks - great job" on this too! :-)

Though in retrospect my question was ill-advised -- I had removed the @ symbols because my version of sbopkg* wouldn't read the queue file -- your response was enlightening and I thank you.


* While a great tool, my usage of sbopkg has thus far been limited to installing packages with which I am already familiar. There is just too much opportunity to learn by manually resolving dependencies, visiting the projects' websites, and perhaps updating packages to more recent releases.