As it stands now even blacklisted packages that are upgradeable are marked. Would not make me a happy camper if upgrading took precedence over blacklists. Would surely screw up my system bigtime

The way to do that is to filter by upgradable packages, then tag all of them (the fastest way to do that is to tag all of the groups on the left), and then hit 'u' to upgrade them. It's a little non-intuitive, I know, but it works well.

That shouldn't happen. Nothing listed in the blacklisted filter should also appear in the upgradable filter, and even if they did, there is no option to upgrade, reinstall, or remove them. Are you sure you are blacklisting correctly? Do the packages in question appear in the blacklisted filter?

I have Plasma 5 from the ktown repository installed on my system, and I've blacklisted them. They all appear in the blacklisted filter, but not the upgradable one. In my /etc/sboui/package_blacklist, I have:

Oh Boy. What a nut I am. I was under the impression that the blacklist was controlled by sbopkg. I could have really messed things up.

Thanks for the tip. Works just like you say now for me.

EDIT - The blacklist from sbopkg had enough effect that I didn't catch on and look for a better way.
For instance, the blacklisted items also showed on the updated list. When you tried to update a red window appeared telling you that the item was blacklisted and giving you a chance to back out

montagdude - feature request....maybe OR this might just be me realizing the strength of sboui..:-)
With sbopkg I'm able to modify the .slackbuild and .info files. The .slackbuild I'll modify to all for the latest version to be built and I also often add the mulitlib suggested options of LDFLAGS="-L /usr/lib${LIBDIRSUFFIX}" so that the packages build as 64 bit and don't accidentally get built with the 32 bit libraries (of course unless I'm trying to build a 32 bit app). The .info package gets modified for pulling the latest version and MD5SUM value available from the developers site. I could eliminate sbopkg from my system and use only sboui if I know how to accomplish the same steps within sboui.

For the 64 bit library reference I'm wondering if this is where the system environment CLO's or install/upgrade modifiers could be used?
For the version control I'm not aware of anyway to make that happen, unless since we are using 'vi' for the read/editor could I actually make the change and exit with ":wq" which would overwrite the existing .info or .slackbuild and when the install happens the edited (local in sbopkg terms) file would be used?

Or have I already forgotten more than I knew at one time?

You can modify the files for a SlackBuild by using the Browse Files option and then editing and saving them. Your changes will get overwritten once you sync the repo, though.

You will still need sbopkg or other similar tool. sboui is not meant to be a full package manager. It relies on the package manager to create and sync the local repository and to install/upgrade packages.

I think you could set LDFLAGS and other environment variables for configure scripts as build options. I'm not sure, because I haven't tried it, but it seems like it should work.

1 members found this post helpful.

Great this is the conclusion I thought of when writing further in my first post. Also with a simple sync the old file is returned. I don't think sbopkg is persistent with local edits after syncing either, so the steps are the same.

Actually sbotools will be the package manager in my case. Since sbotools is also a package manager and can be used in place of sbopkg.

I'll give it a try and leave feedback here. If nothing else I can always simply Browse files and with the reader/editor of 'vi' the LDFLAGS can be added to the .slackbuild.

Not sure what to make of this. sbopkg showed Leafpad, elinks, lame and virtualbox-kernel as being upgradable. sboui didn't pick any of them as upgradable.

I used sbopkg to upgrade them

Is it possible you had some of those installed from another repository (e.g. alien), and they were blacklisted? Did you happen to write down the installed versions prior to upgrading?

For virtualbox-kernel, I have a hunch that sbopkg may have thought it was upgradable when it really wasn't due to the kernel tag that is added to the end of the version number, but I'm not familiar enough with how sbopkg handles packages like that to say for sure.

I have copies of all. They are not blacklisted, I checked that first. Not a big deal for me but sure is curious

leafpad-0.8.18.1-x86_64-1_SBo

lame-3.99.5-x86_64-1_SBo

elinks-git20131231-x86_64-2_SBo

virtualbox-5.0.40-x86_64-1_SBo

1 members found this post helpful.

Okay, thanks. I'll look into it.

Going by the version number, those are all the latest releases. However, the SlackBuilds for leafpad, lame, and elinks were all updated recently without changing the version number. sboui checks whether a package is upgradable by comparing the version number in the installed package with what is in the .info file, so that's why none of them were marked as upgradable by sboui. sbopkg must check the SlackBuild scripts themselves for changes. I wonder if it would be better to do it that way in sboui. That might introduce complications with blacklisting, though. I'll have to give it some thought.

Ideally, if a SlackBuild (or info) is updated without a new version number, the $BUILD should be incremented. I checked lame and that was the case there (went from BUILD 1 to BUILD 2). Pat does the same thing with the official tree (incrementing BUILD if the version didn't change), so it might be something to consider adding to yours, as I imagine this is one of the things sbopkg checks to determine upgrades.

2 members found this post helpful.

Yup, I think you are right. It would be fairly simple to add the BUILD number to the check for upgradable packages, and I don't think it would cause problems with anything else.

When SBo increments BUILD, it's a signal to people that they will probably want to redo an existing package. If an update just fixes a broken DOWNLOAD url, or corrects typos in the README, or maybe adds new optional deps, we don't increment BUILD. It's not a "revision number" for the SlackBuild script: we've got git for that, or the ChangeLog if you prefer.

Furthermore, it's my (controversial) opinion that the user (or the tool) should sometimes override the SlackBuild's default BUILD number in the resulting package's name -- for example, if package B needs a rebuild because it depends on a new version of package A, or because you want to change some options, are you going to use the same build number? And if you increment the package's build, what are you going to do later, if the SlackBuild gets a new BUILD?

1 members found this post helpful.