[SOLVED] sbotools and slackpkg+ -- repo priority

Gerard Lally · 07-29-2016, 09:42 AM

Quote:

Originally Posted by stormbr

I do something like you but I don't install sbos directly. I put them in a private repo and install from there. I have never had this problem.

So the idea is to use sbotools just to build the packages without installing them and then use slackpkg+ to install them, giving the local repo an appropriate priority? Nice thinking, if so.

a4z · 07-29-2016, 10:11 AM

Quote:

Originally Posted by gezley

So the idea is to use sbotools just to build the packages without installing them and then use slackpkg+ to install them, giving the local repo an appropriate priority? Nice thinking, if so.

you can install them anyway directly with sbotools,
if they are also put into a local/private repo, it's just that slackpkg+ finds the files in the repo (changelog) with a higher priority and respects them.

so configure sbo to spot out packages in a location you like and make a repo out of that.
if you maintain a lot of computers you might want to upload the sbo build packages anyway so that all can make use of them.

this thread helps with details about making a local repo

montagdude · 07-29-2016, 10:14 AM

Quote:

Originally Posted by Slax-Dude

I could be wrong, but I believe sbotools only fetches source code + slackbuild, then compiles it with all defaults, then (optionally) installs the resulting package.
If that is so, then it is no different than using the slackonly repo.

If, however, sbotools actually allows a user to specify any optional dependencies or parameters, then said user can build a local repo with just the required packages and point slackpkg+ to the resulting repo.

My point is: it is best to avoid using several package managers that may or may not be aware of each other's installed packages.
And since slackpkg+ is able to use the official slackware repos as well as third-party repos, it is a clear winner for me. Kudos once again to zerouno for making such a marvelous "plugin" (and also to all that contributed code and ideas to it).

In an ideal world, slackpkg+ would be merged with slackpkg and included in slackware proper pre-configured with repos trusted by the BDFL himself (he already publicly stated he trusts alienbob's repos by using Slackware's GPG here and here and I'm sure he trusts others in the core team as well)

There are some advantages to using the tools designed for interacting with SBo, like automatically installing dependencies and letting you see the contents of README and .info files. Maybe sbotools does that too (EDIT: I meant installing to a local repo, confirmed by suppy in post 23), thus letting you have the best of both worlds. (I don't know because I haven't used it.) The one downside to that would be having to store the repo locally somewhere, but if you don't care about that it might be a really good option.

bassmadrigal · 07-29-2016, 10:24 AM

Quote:

Originally Posted by gezley

So the idea is to use sbotools just to build the packages without installing them and then use slackpkg+ to install them, giving the local repo an appropriate priority? Nice thinking, if so.

If you're interested, David Spencer's (55020 on the forum) slackrepo program does exactly this. It will build the packages and their dependencies from SBo and make them available as a slackpkg+ ready repo. It can even make a clean chroot environment for each build session so you can keep your build environment clean. You can also use hintfiles to supplement the .info files for those optional dependencies, creation of user/group, updating versions/md5s/download locations/etc without modifying the original .info file. It is extremely powerful and it's a really impressive piece of software.

Gerard Lally · 07-29-2016, 10:53 AM

Quote:

Originally Posted by bassmadrigal

If you're interested, David Spencer's (55020 on the forum) slackrepo program does exactly this. It will build the packages and their dependencies from SBo and make them available as a slackpkg+ ready repo. It can even make a clean chroot environment for each build session so you can keep your build environment clean. You can also use hintfiles to supplement the .info files for those optional dependencies, creation of user/group, updating versions/md5s/download locations/etc without modifying the original .info file. It is extremely powerful and it's a really impressive piece of software.

This looks good. But now the million dollar question: how likely is it these tools (sbotools, sbopkg, slackrepo, others?) will be around in two, three, four years' time? At least sbotools is at slackbuilds.org.

Gerard Lally · 07-29-2016, 10:57 AM

Quote:

Originally Posted by a4z

you can install them anyway directly with sbotools,
if they are also put into a local/private repo, it's just that slackpkg+ finds the files in the repo (changelog) with a higher priority and respects them.

aha -

!

So install them with sboinstall, but keep the packages in a local directory and tell slackpkg+ about this repo, so it doesn't downgrade them? Beginning to get a picture of the workflow here. Very nice.

bassmadrigal · 07-29-2016, 12:45 PM

Quote:

Originally Posted by gezley

This looks good. But now the million dollar question: how likely is it these tools (sbotools, sbopkg, slackrepo, others?) will be around in two, three, four years' time? At least sbotools is at slackbuilds.org.

Well, David is now an admin for SBo. According to his commit log on github, he's been working on slackrepo since Nov 2013 and it's still going. I believe he used it during SBo's work towards getting all the SlackBuild scripts building on -current. He would send out the occasional email on the SBo mailing list informing everyone what programs weren't building (assuming he didn't fix them himself... which he fixed A LOT himself).

Plus, even if it was abandoned, unless SBo has some monumental shift in how they provide packages, it should continue working without issue.

As for sbopkg, it is being maintained by willysr, who is also an SBo admin (and, according to the copyrights at the top of the script, 4 people have had a hand in the script, dating back to its inception in 2007).

I think these programs are in good hands

As for why those aren't in SBo, it might be because they are just shell scripts and don't require any compiling.

suppy · 07-30-2016, 07:21 AM

Hi, maintainer of sbotools here, and while I haven't used slackpkg+ myself, I'd say the idea of having a local repo where the packages gets moved to sounds like the best solution; you can easily automate this by setting the PKG_DIR option in sbotools.conf -- see man sbotools.conf -- which will move the packages to the specified directory after they've been installed.

The idea of not letting sbotools actually install the packages itself is less than ideal, because then anything that has a dependency will fail to build as the deps do need to be installed when building.

Quote:

Originally Posted by Slax-Dude

I could be wrong, but I believe sbotools only fetches source code + slackbuild, then compiles it with all defaults, then (optionally) installs the resulting package.
If that is so, then it is no different than using the slackonly repo.

If, however, sbotools actually allows a user to specify any optional dependencies or parameters, then said user can build a local repo with just the required packages and point slackpkg+ to the resulting repo.

And yes, you are wrong. sbotools will allow you to set any options the slackbuild has as well as run any needed useradd/groupadd commands for you; optional deps will need to be listed on the commandline though.

Gerard Lally · 07-30-2016, 10:38 AM

Thanks for the insights, one and all. I'll probably settle on the simple blacklisting solution proposed by phenixia2003. It's elegant, and quickly done.
I'd also like to pay a small tribute to the developer and maintainers of sbopkg, which I neglected to mention in my OP. It's no longer niggly to set up, since sqg is now in /usr/sbin, and it's a lot more sophisticated than I gave it credit for when I tried it some time ago. Both sbopkg and sbotools have nice features, so not sure which one to choose yet, but thanks to Sebastien the immediate problem I had is now resolved.

zerouno · 07-31-2016, 06:55 AM

I just want to add a tip regards the dir:/ repositories.

Unlike a local repository (file:/), a directory repository does not need to create metadatas with any tool.
Just put a package into that directory (for example by setting PKG_DIR in sbotools.conf) and it is in slackpkg+ even if you don't run slackpkg update

If you have already installed a package and have not the txz, just create an empty file in that dir to blacklist that package
# touch sbodir/package-123-i386-1_SBo.tgz
and slackpkg upgrade-all will not search it in other repositories.

However yes, I agree that the /etc/blacklist file may be the best way (and the official slackpkg way)