LinuxQuestions.org - [SOLVED] pkgtools/slackpkg(+,) slapt-get, sbopkg/sqg, autoslackpkg, hoorex, mkslack, sbotools, sboui, slackroll, slackyd, slpkg, spkg, spman: which?

- Slackware (https://www.linuxquestions.org/questions/slackware-14/)

- - pkgtools/slackpkg(+,) slapt-get, sbopkg/sqg, autoslackpkg, hoorex, mkslack, sbotools, sboui, slackroll, slackyd, slpkg, spkg, spman: which? (https://www.linuxquestions.org/questions/slackware-14/pkgtools-slackpkg-slapt-get-sbopkg-sqg-autoslackpkg-hoorex-mkslack-sbotools-sboui-slackroll-slackyd-slpkg-spkg-spman-which-4175675399/)

pkgtools/slackpkg(+,) slapt-get, sbopkg/sqg, autoslackpkg, hoorex, mkslack, sbotools, sboui, slackroll, slackyd, slpkg, spkg, spman: which?

Pkgtools were probably on the old official Slackware CD I tried in the 1990s, and I used and programmed for Slackware more & more since (though had a short desktop break until recent drivers, still used Slackware for servers)... a bit newer than pkgtools are official slackpkg and unofficial slapt-get, sbopkg/sqg, autoslackpkg, hoorex, mkslack, sbo-templates, sbotools, sboui, slackpkg+, slackyd, slackroll, slpkg, spkg, spman, even more than that... what's good for what?

Slackware does have dependency management: Patrick Volkerding makes sure each release has all dependencies if you do a full installation, and any new upgrades (mostly for security) will have dependencies at that time. You don't manage its dependencies on your own (except for example, if you install in a server you may not have much space, don't need X, but if it runs a site, you might need some X libraries, so you learn that advanced knowledge on your own.)

Apart from official package tools, first I mostly used sbopkg since '00s, then switched to sbotools (though sbopkg has sqg, which makes it just as powerful, and I saw one or two errors in sbotools sbopkg didn't make)... then I started using slackpkg+ with more repositories, sometimes even SlackOnly.com... then I tried slpkg, which if I recall correctly (IIRC) did some new things I liked, but couldn't figure out some things about it (a few years ago, kept saying it needed an update which wasn't in its repository) nor could figure out how to use sboui for multiple repositories (but seems it would be very nice to use)... now there's also autoslackpkg, which if I could figure out how to blacklist & greylist right, might also be powerful.

There were some difficult things to learn about each tool, but they saved a lot of time, even in the case that they manage dependencies (just not ones that won't cause the official Slackware to not boot, as far as I know)... for any/all of these, what are some things some do that you think they might do better than others? If you use most/all, would you use different ones for different things? Are there any other Slackware package tools you are aware of (ignoring stuff like dpkg or rpm, which I typically would never use... but past tools to build/install BSD Unix packages were interesting.)

If you build packages and submit them to SlackBuilds.org (or another public repository) of course also comment in relation to that and/or any package build tools (or ones named slack*, or that do similar things) if might be interesting...

If I recall correctly, slapt-get might've been the earliest unofficial, and in the '00s I almost/fully ruined my system with it, but if one knows about it, it might be useful, and Salix package management tools might be useful in some case (even graphical in the case you might administer a PC for users but they might want to view & install packages.) I mean, if a server has a password anyway, why not use a tool that might make updating some things easier (is that the case with Salix?) Currently I don't on my servers for some reason (something else the Salix fork did) but maybe it was easier for somoene elses's server (even if I think I might still not try that.)

Maybe because of what everyone used to say about slapt-get (and why they don't use it unless they understand it well) it's strangely the case that on Usenet and some of the original Internet Relay Chat (IRC) some people still don't even want to use the official slackpkg. Slackpkg never caused a problem for me, but it was once the case something unexpected happened with slackpkg+ that I had to reinstall slackpkg (i.e., maybe even boot install .ISO to rescue, find & reinstall slackpkg with a special argument/flag/switch to mean in /mnt rather than /!)

Of course the sbo* tools, slpkg, etc., can also do such things: if you use current, they might overwrite system packages with older versions for stable, from before when those packages were brought in (unless you can select 'clear installed,' like in sbopkg; unsure about sbotools or others.)

So in summary, be extremely careful with any unofficial tool (or quasi-official ones, as one repository is run by Slacksware team members, so I consider the repository/tool quasi-official, but most the packages unofficial) because unexpected/error things can happen... if you learn a tool and get used to it, that becomes less likely...

Personally I like slackpkg for official system updates & (carefully) slackpkg+ (for prebuilt repositories,) sbopkg if I want to read through the unofficial package lists (but sbopkg and the Slackware installer need to expand the boxes to more rows & columns for modern monitors, as a friend of mine explained is possible with GNU Dialog,) but mostly sbotools to install those (or sbopkg if it didn't work)... sometimes I might've used slpkg if I was trying repositories not in slackpkg+ yet, or just to learn different tools... still want to learn sboui and autoslackpkg (every night I already get update lists with cron and almost every day do updates sort of likeautoslackpkg does, so see no reason to keep typing it all out...)

As for me, sbopkg has command line switches for most of usage cases, so no any need to see dialog windows ;-)

I can help with autoslackpkg. You mention slackpkg blacklist and slackpkg+ greylist as hurdles to work through. Start with the blacklist, post a copy and let's take a look.

I like and use official Slackware tools on my Slackware64-current desktops and laptops(pkgtool, slackpkg). I also appreciate and use sbopkg to manage my third party applications. I rarely compile applications from source, but, I appreciate that Slackware allows me to do that.

Quote:

Originally Posted by Chuck56 (Post 6124220)

I can help with autoslackpkg. You mention slackpkg blacklist and slackpkg+ greylist as hurdles to work through. Start with the blacklist, post a copy and let's take a look.

Thanks for offer. It'll be some hours/days/weeks before I get back to that stage. What I recall happened in slackpkg+ is I blacklisted a few packages... they were still installed... maybe I even blacklisted an entire repository except for specific packages--if possible--but that didn't do much. It's been a few years since I used it (since temporarily switched on desktop for amdgpu drivers, but use Slackware on laptop and servers without many packages) but actually I may not really be using it much until next stable Slackware .ISO, because otherwise I can't use most repositories; I'm on Slackware-current.

I noticed on upgrade to Slackware-current, sbotools were broken... I think recompiling them fixed it... except what repository to specify. I switched to mostly using sbopkg but build the queues with sqg... sbotools handles queues, which would be quicker often (except browsing) because it's command-line...

This hasn't been widely tested, but you should be able to use sboui for multiple repositories by creating an additional configuration file, then calling it like this:

Code:

sboui -f /path/to/custom/sboui.conf

At a minimum, the new configuration file will need a different repo_dir and repo_tag. However, you will also need to configure the backend package manager to use the alternate repository. If you are using the built-in package manager, you can need an additional configuration file (sboui-backend.conf) for that purpose and point to it with the CONF environment variable in sboui. The most consistent way to do that would be to set it in your custom sboui config file, like this:

Code:

# Partial contents of /path/to/custom/sboui.conf

repo_dir = "/var/lib/sboui/alternate_repo"

package_manager = "built-in"

install_vars = "CONF=/path/to/custom/sboui-backend.conf"

upgrade_vars = "CONF=/path/to/custom/sboui-backend.conf"

And then, finally, in your custom sboui-backend.conf:

Code:

# Partial contents of /path/to/custom/sboui-backend.conf

REPO_DIR=/var/lib/sboui/alternate_repo

Like I said, this is not well tested, so if you try it, let me know what works or doesn't. One issue I can see right away just by looking at the code is that if you use the UI to change options, it is going to overwrite the main config file rather than the custom one, so don't do that. I will put it on my list of things to fix.

What's good for what? Well I can only speak to slackpkg with slackpkg+. I've always used slackpkg to keep my system updated. Before slackpkg+ I used pkgtools primarily for 3rd party packages using blacklist to make sure I didn't accidentally on purpose remove 3rd party program with 'slackpkg clean-system'.

Then slackpkg+ came out. That was a game changer. Once you have a handle on how slackpkg+ works with slackpkg it make upgraded a piece of cake. I no long need entries in blackist for third party packages. I created my own repository for my builds and mirror everything except for slackpkg+ and slackpkgbeta. There is no download time when I do an upgrade across my LAN. Each system has a few 3rd packages differences that are handled by slackpkgplus.conf. I also make use of graylist and notifymsg.conf.

I maintain one desktop and three laptops. I've never really tried any of those other programs as I am quite satisfied with slackpkg with slackpkg+.

How chrisretusn does things also sounds amazing. I was just going back through sbopkg and found several other package tool, management, build, tracking, etc. programs... some had unusual names, like weren't slack*, sl*, s*... I'll have to go back through and add them to the list unless someone does. They weren't all in the same category maybe. I think one started with m.

Looking through SlackBuilds again, the number of package/build-script download, build, installation, creation, management, tracking, etc. tools is simply amazing. Others I'm wondering about now are porg (Slackware-specific or not,) conan (C/C++-specific, but Slackware-specific,) and there are probably 10+ others, not just dpkg & rpm (feel a little sick now, but one might only want to make a directory to view/decompress such, then if it might work without Debian/Redhat aspects, or what dependencies are) and also many tools for using/building other language (Perl, Python, ...?) packages on Slackware.<br><br>

I admit, though I also have Slackware laptop, servers, I'd been away from it on desktop for a couple years for display drivers (which kingbeowulf now built.)<br><br>

Even noticing the package install/build/maintain/track possibilities since then is really amazing but I have to get up to speed, and it looks like any new users might have some weeks/months just trying these approaching 20 different ones (I couldn't list some above, like findpkg, listpkg sound like pkgtools but unofficial...

Magiic is another I found...

I dunno, Man. I see posts regularly from people having problems due to package automation. It seems to me any time saved is outweighed by problem solving. I just use pkgtools and never put my system at risk. Maintenance is almost non-existent. I prefer manual transmissions too so I'm probably really Old Skool ;)

I use slackpkg+ since it came out (thx zerouno and phenixia2003 for making it what it is today) and like it a lot.

The only thing I would like to see in it would be a separation between the .conf file and the repo list.
Something like a repo folder and in it the tool would find some repo.conf files, one for each repo, with name and address for the repo.
This would do 2 things:

each repo could have a slackware package for it, that would simply place the text file in the repo folder, which could be easily installed and uninstalled by newbies
since the tool would find the repos in a folder and not in the .conf file itself, there would be no problems updating the .conf file when a new version (with new syntax) came out

This would also allow the repo to update the address in case of a change:
Lets say AlienBOB had alienbob.repo-14.2-x86_64-1alien.txz, which defined the name and address for his repository of packages for slackware64_14.2, with x.alienbob.com as the repo address.
If, for some reason, he decided to move it to y.alienbob.com then he would only have to issue alienbob.repo-14.2-x86_64-2alien.txz package with the updated address and slackpkg+ would update it.

Just a thought :)

I haven't tried most of the tools you've mentioned. Relative to some of you I haven't used Slackware that long (and I use a couple other systems too), so maybe some day. Generally my approach with new operating systems is to start with basics and expand out if it's too much labor. Note that I use 14.2 (and sadly probably will for some time after 15.0 unless I do something about the data cap on my internet connection or there's a DVD).

slackpkg: only when there is more than two or so updates to do at once, often when kernel updates come. Always when I've not booted into Slackware for awhile and have many to do. If only one package has a security update I download it using a trivial script I wrote that also checks the signature. With that being one command and upgradepkg the second it is not more work than running slackpkg. And I find myself reading slackpkg's man page every time I run it because I forget how it works.

/usr/local normal builds: this was my only other way for awhile and I enjoyed doing it. I wrote a little scripting to keep track of where things go in a very simple way but it needs more work. I haven't bothered to remove much yet and make uninstall or putting what Perl distribution's make uninstall tells you it would do if it dared into a script and running that, these both seem to work surprisingly well if you remember to do the uninstall before the install of the new version.
But programs with many dependencies are too laborious this way. At a certain point you figure, I might as well do LFS (I'm now doing that and just starting ch 6, at one build a day).

slackbuilds.org: in the last couple years I've favoured this over my own builds. I like it only directly from the git repo. I'd used a tool with a menu (sbopkg?) but didn't care for it, no offense meant to its authors, that's only personal preference. It had the slackbuild tree in a whole different place than I put the git workspace. Before long I wiped that out and stuck to the git tree. I never bothered to learn much about queues, though I think I used some in the menu system when my son was over and wanted games.
But programs with many dependencies are also too laborious this way. For awhile I had the stamina and liked to generate a list of the dependencies from the info files using a script I wrote, then manually install them a day at a time ticking them off in the file. Then one day I decided I should install shellcheck as preparation to one day try my hand at a slackbuild for picolisp (I no longer have the interest, sorry. Really, you'd be as well off if not better off installing picolisp directly from source.) Well, I got through the python deps for the documentation system it uses and even started in on the haskell deps, but I haven't touched it in nearly a year.

abstinence: if you have to have that many dependencies maybe I don't want to run your software.

pkgsrc: recently I've been running netbsd 9.0 because it's pulled in the nouveau DRM driver from Linux, enough to kind of support my nvidia card. It also has ZFS, which is fun to use, except deleting many files is weirdly slow. More as an exercise in learning pkgsrc than to get packages to slackware I tried it here. But I wanted to force it to use native slackware libraries as much as possible and hit a snag. I hope to find the bug myself someday, but I've lost some enthusiasm for chasing it after narrowing it to this sed statement:

Code:

sed -e '/^dependency_libs=/s,\([\ `"'\'':;,]\)/usr\(/lib64/[^\ `"'\'':;,]*lib[^/\ `"'\'':;,]*\.la[\ `"'\'':;,]\),\1_bUiLdLiNk__usr_local_pkgsrc_textproc_libxslt_work_.buildlink#\2,g' -e '/^dependency_libs=/s,\([\ `"'\'':;,]\)/usr\(/lib64/[^\ `"'\'':;,]*lib[^/\ `"'\'':;,]*\.la[\ `"'\'':;,]\),\1_bUiLdLiNk__usr_local_pkgsrc_textproc_libxslt_work_.buildlink#\2,g' -e '/^dependency_libs=/s,\([\ `"'\'':;,]\)/usr/local/pkg\(/[^\ `"'\'':;,]*lib[^/\ `"'\'':;,]*\.la[\ `"'\'':;,]\),\1_bUiLdLiNk__usr_local_pkgsrc_textproc_libxslt_work_.buildlink#\2,g' -e '/^dependency_libs=/s,\([\ `"'\'':;,]\)/usr/local/pkg\(/[^\ `"'\'':;,]*lib[^/\ `"'\'':;,]*\.la[\ `"'\'':;,]\),\1_bUiLdLiNk__usr_local_pkgsrc_textproc_libxslt_work_.buildlink#\2,g' -e '/^dependency_libs=/s,\([\ `"'\'':;,]\)-L/lib64\([\ `"'\'':;,]\),\1\2,g' -e '/^dependency_libs=/s,\([\ `"'\'':;,]\)-L/lib64\([\ `"'\'':;,]\),\1\2,g' -e '/^dependency_libs=/s,\([\ `"'\'':;,]\)-L/lib64/\.\([\ `"'\'':;,]\),\1\2,g' -e '/^dependency_libs=/s,\([\ `"'\'':;,]\)-L/lib64/\.\([\ `"'\'':;,]\),\1\2,g' -e '/^dependency_libs=/s,\([\ `"'\'':;,]\)-L/usr/lib64\([\ `"'\'':;,]\),\1\2,g' -e '/^dependency_libs=/s,\([\ `"'\'':;,]\)-L/usr/lib64\([\ `"'\'':;,]\),\1\2,g' -e '/^dependency_libs=/s,\([\ `"'\'':;,]\)-L/usr/lib64/\.\([\ `"'\'':;,]\),\1\2,g' -e '/^dependency_libs=/s,\([\ `"'\'':;,]\)-L/usr/lib64/\.\([\ `"'\'':;,]\),\1\2,g' -e '/^dependency_libs=/s,\([\ `"'\'':;,]\)-L/usr/local/pkg/[^\ `"'\'':;,]*\([\ `"'\'':;,]\),\1\2,g' -e '/^dependency_libs=/s,\([\ `"'\'':;,]\)-L/usr/local/pkg/[^\ `"'\'':;,]*\([\ `"'\'':;,]\),\1\2,g' -e '/^dependency_libs=/s,\([\ `"'\'':;,]\)-L/usr/local/pkg/[^\ `"'\'':;,]*\([\ `"'\'':;,]\),\1\2,g' -e '/^dependency_libs=/s,\([\ `"'\'':;,]\)-L/usr/local/pkg/[^\ `"'\'':;,]*\([\ `"'\'':;,]\),\1\2,g' -e '/^dependency_libs=/s,_bUiLdLiNk__usr_local_pkgsrc_textproc_libxslt_work_.buildlink#,/usr/local/pkgsrc/textproc/libxslt/work/.buildlink,g' -e '/^dependency_libs=/s,^\(dependency_libs='\''\) *,\1,g' -e '/^dependency_libs=/s, *'\''$,'\'',g' -e '/^libdir=/s,/usr\(/lib64/[^\ `"'\'':;,]*\),/usr/local/pkgsrc/textproc/libxslt/work/.buildlink\1,g' -e '/^libdir=/s,/usr/local/pkg\(/[^\ `"'\'':;,]*\),/usr/local/pkgsrc/textproc/libxslt/work/.buildlink\1,g'

To be fair to the pkgsrc people, I see them concluding on their mailing list (an unrelated thread, I'm putting myself in a probation period and not writing them until more familiar with their community) that you'll have more fun on non-NetBSD systems if you set it to prefer the pkgsrc version of a dependency to the native one. If I did that I expect pkgsrc could nicely fill the gap I have of installing large junk with lots of dependencies in less than six months.

If not for pkgsrc, or if I give up on it completely, and if I feel a need to give up on the abstinence, probably it will be time for me to try one of the tools you mention that try to build dependent packages, maybe slapt-get (though there was another one in Perl which is attractive to me). pkgsrc is nice in that the automatic dependency installing never escapes /usr/pkg. But the downside to that is you get different versions of the same thing installed in two different places. That may not be a problem for the loader, thanks to how pkgsrc religiously uses -rpath, but it might confuse me.

But right now I'm not looking to install new things. At best I might want an mpv other than the old one I manually did, but its dependencies aren't crazy like shellcheck. I'm abstaining on spellcheck. ksh -n will have to do. And mpv is coming in 15.0, right?

I got slackpkg blacklist, greylist working now.

Another set of tools recently being discussed in a LQ thread is slackup.

Apparently recently spkg is faster than installpkg.

For system packages I use slackpkg with blacklist for my and sbopkgs.
Used to use sbopkg for slackbuilds, but lately been fan of sbotools. fast and easy + dep check :)