Update: See http://www.linuxquestions.org/questi...ml#post3607902 about sbopkg 0.30.0beta.

We have released an alpha of the upcoming sbopkg 0.30.0, which has some major cleanups and changes that hopefully folks will find useful. I would love to get a lot of testers for this alpha. Here is a small, edited list of just some of the items in the -trunk ChangeLog:

* Move sbopkg to /usr/sbin and remove code related to user-mode support; sbopkg must now be run as root in all cases.
* Apply a major code cleanup that touches just about every part of sbopkg. This cleanup makes the code more readable, manageable, and less bug-prone. Several bugs were fixed as part of this cleanup, and the cleanup will ease further development and debugging efforts.
* Implement configurable repository support by introducing a new /etc/sbopkg/repos.d directory where separate repositories files can be maintained and also by adding support for git-based repositories. The
Slamd64Builds repository is now listed, to the joy of all the Slamd64 users out there. Conceivably, other Slackware-related distros could maintain their own repositorites and integrate them with sbopkg.
* Move sbopkg-renames to new /etc/sbopkg/renames.d/50-default to manage multiple renames files.
* Add support for new *.txz, *.tlz, and *.tbz Slackware package extensions.
* Create a ChangeLog.txt for git repos on the fly.
* Change queuefile format. No longer will the queuefile format be 'APP VERSION ON/OFF' but instead will simply be one 'APP' per line. If a user wants an APP to be deselected in the dialog menus, simply put a '-' in front of it, e.g. '-APP'. This should make creating, using, and sharing queuefiles much easier and more intuitive. See www.sbopkg.org/queues/12.2 for samples.
* Add ability to load more than one queuefile at a time when building from command line interface.
* Add several new functions related to checking GPG-signed tarballs, such as those that SlackBuilds.org provides. Sbopkg will now automatically check these tarballs when building or installing a package. Additionally, there are two new menu items in info_item that allow the user to check the GPG signature or re-extract the GPG-signed tarball.
* Add ability to dump all installed packages into a build queue. This is an alphabetical list, so shuffling/reordering of the queue will be necessary in order to list the dependencies correctly, but at least this will give users a head start on setting up a large build queue.
* Add ability to have recursive queuefiles, so one queuefile named "foo.sqf" may have an entry "@bar" in which case as the foo.sqf queuefile is parsed, it will recursively go down into the 'bar.sqf' queuefile as well. The '@' symbol is used in front of an entry in a queuefile to denote another queuefile.
* Add ability to pass build options in a queuefile when separated by a pipe character, i.e. app | FOO=yes BAR=no
* Add a 'diff' entry to the script customization menu.
* Add in 'uname -m' test for x86_64 and if true, set ARCH to x86_64.

The full -trunk ChangeLog.txt is here.

We would really like to get some testers of this alpha release. Of course, being an alpha release, there may be serious bugs so I would not recommend using this on a production system (although since I eat my own dogfood, I use this alpha release on all my systems). Perhaps if you are testing slackware-current in a virtual machine, you might want to try out this alpha release.

Here is the mailing list announcement with more details. Please read this ML announcement before installing the alpha since it provides additional information. If you have a current -stable release of sbopkg installed, I recommend uninstalling it and installing the new alpha instead of doing an upgrade. Both the sbopkg.conf and the directory layout have gone through major changes, so while it might be possible to migrate your current data to the new install, it might just be easier to let sbopkg make the new directories and perform a fresh rsync. Please make a backup of your local rsync copy and sbopkg.conf if you have made any changes to them.

Here are direct links to a package and source tarball of sbopkg-0.30.0alpha1:

Package:
http://sbopkg.googlecode.com/files/s...arch-1_cng.tgz
Tarball:
http://sbopkg.googlecode.com/files/s...0alpha1.tar.gz

Feel free to post your feedback here, to the #sbopkg IRC channel, or on the sbopkg ML (preferable).

Thanks!

Thanks for your great work Chess.
If I find anything suspicious, I'll report back.

Chess,

I am in awe of you folks who can develop tools like this. Congratulations to you and everybody involved!

With that said, I now will commit Slackware blasphemy.

Is there any chance of creating a graphical interface for your tool? Something like Synaptic (Debian) or XNetpkg (Zenwalk)? I mean graphical as in a QT interface. (Well, GTK too, I guess, but I think QT is better. )

I ask because in another thread, several people have recognized that although many Slackers build their own packages, many also do not for various reasons. In that same thread the topic was raised of a central large repository. At one time that central location was linuxpackages.net. That site seems to be winding down and losing popularity. Currently the only large central repository with precompiled packages is slacky.eu.

Your tool alleviates the need for a central repository because many repositories can be added to the search list.

Additionally, for those seeking precompiled packages, your flexible tool can build packages for those who do not want to fiddle with that task. For many such end-users then, there really is no difference between building on-the-fly or downloading complete packages.

Your tool can become a great portal for people who do not want to build packages and only want to download them. Your tool can be used to create the illusion of a large central repository by searching several repositories.

One challenge is using the command line and an ncurses tool. Yeah, I know, we're discussing Slackware here, but point-and-click is here to stay. Many people judge a modern computer operating system by such tools.

Many people who might like the Slackware design move elsewhere because of the lack of a large central repository. With a pre-populated sources list, your tool could quash that argument. Second, many people would rather use a graphical interface. Many people like the design of Slackware but do not necessarily want to get too deep under the hood. A graphical interface for your package manager would alleviate much resistance for many people.

The Zenwalk people have a package manager that is both ncurses and graphical. The PCLinuxOS people have adapted Synaptic to managing RPM packages. I envision your tool becoming part of that same club.

I want to emphasize that I do not want to downplay or discredit your great utility. Some hard-core Slackers will agree I just committed blasphemy. So be it written, so be it done. I simply believe a graphical interface would be a great selling point --- a significant bonus.

I just spent about 15 minutes looking through the sbopkg code.

A PyQt4 port would be possible. The problem, however, isn't writing it; it's maintaining it in parallel with the original branch. If the fork is done by Chess, he would have two completely different programs to maintain simultaneously. The extra overhead could quite possibly cause both to suffer. If someone else ports it, that person would have to commit to porting all of Chess's future releases as well. I'm not volunteering.

You need to understand what I mean by "porting." It means rewriting every line. You can't just rewrite the "interface" because in sbopkg's case, that won't work. All 4201 lines of the program will have to be rewritten.

If Chess declines to do this, I will certainly understand.

Anyone else want to step up?

I just like the fact that it works. I am testing the 0.30.0alpha1 on Slackware64-current and all seems to be working. So what if the interface is written in dialog, slackpkg is command line only, pkgtool is dialog, they are admin tools they don't need fancy bells and whistles, they just have to work.

samac

Also, sbopkg is already extremely efficient and easy to use. Designing a GUI with a tangibly improved interface (and not just reproducing the dialog menus), that would take advantage of a graphical widget set, would take more than a little thought.

That's true even if the plan is to base the UI on another package manager.

I'm not saying it can't or shouldn't be done. I just want everyone to be clear on what the scope is.

I don't underestimate the scope, which is why in the first sentence of my post I provided some praise for folks who can develop these tools. Way beyond my skills!

What about something like Xdialog? That tool is not QT, but doesn't that tool act as a wrapper? Or --- and this is up to Chess --- how about maintaining only one version --- a graphical version, say a PyQt version?

Slackware often is criticized for not having any graphical administrative tools. Some people will say that's not the "Slackware way." To me, the "Slackware way" is that Slackware does not get in my way. Yet I'd like to see more non-technical users find a home with Slackware. A graphical front-end for package management would provide a nice tool for such people.

Veteran Slackers know that the existing tools emphasize function over form. A little glitter doesn't hurt, however.

I'll respond to this later...

Come on, Woodsman. You know there are very good reasons to not want to see that happen. What about the people running servers, who choose not to install X? What about the people who don't want to install the library dependencies, or running old machines on which graphical python code runs unacceptably slow?

If you really want a Synaptic-style program with all of sbopkg's functionality to exist, why don't you get it started? Post a set of designs for what the interface should look like. You can do them in Gimp, Inkscape, or scanned paper. Cover all the major functionality. Anyone taking this on will begin by designing the interface anyway.

Just for the sake of this discussion, I tried making an Xdialog version of sbopkg. Well, I didn't "make" it. I did one global search and replace . It's here:
http://www.vcn.bc.ca/~dugan/xsbopkg

That should satisfy anyone's curiosity as to what an Xdialog version might be like.

My opinion: it's a great example of why Xdialog is never used.

Hey, thanks everyone for the feedback, it is greatly appreciated. I'm glad that folks are interested in sbopkg and finding it helpful/useful. Samac, thanks for letting me know that so far the alpha is working ok for you. Adriv, please do let me know if you come across problematic.

Woodsman, as to the GUI/QT port/fork issue, I don't really have much to say on it at this point. It's not something I've spent any real time thinking about, and I'd probably want to mull that over a long time before committing one way or the other. I appreciate the thoughts on the issue, though, and it definitely is something worth spending some time thinking about. Of course, being free software, folks are free to do what they want with the code in the meantime.

And dugan, thanks for the xdialog example. :-) That is something I *have* thought about before, and always wondered what it would look like in an xdialog interface. Now I know.

Please keep testing the alpha and let me know of any successes or failures. We want this to be a really solid release, in keeping with all the cool stuff happening with -current.

Well done to the developers an excellent tool. My only suggestion is that the menu structure and navigation is an area for improvement, I have got lost a couple of times.

We don't need no Synapticified sbopkg.

I had never used Sbopkg before today, but I have it installed and building Torcs as I type. I read the build script (I'm no expert) and it seems to be just fine as is for Slackware64-current. My grandson loves this racing game, and this is a brand new install fully updated. I'll let you know how it turns out.

Thanks for at least considering the ideas. I'm well aware that you need and want to focus on the next release, but hopefully thereafter the idea might start sounding nice to you.

And who is 'we' Kimosabe?

Uh, me, and...uh...