You would enter those options in the options window under "Upgrade environment vars." For installs or reinstalls, you would use "Install environment vars." If there are any that you want to persist, you can put them in the configuration file.

Thanks for the hint. I've uncovered some things which maybe bugs or user error, so would like to ask for your instructions again.

It wasn't intuitive to look for package options to be entered on the same screen where a user is expecting global settings? I thought the Options screen was all about the sboui "global" settings for User Interface/Color/Package Manager and not for individual package builds.

Looking at the global settings I notice Install/Upgrade commands are sboinstall -r and sboupgrade -r, which ignores dependency checking and interactive communication with the CLI during the build. I was thinking to solve my issue, noted in last post, by removing the -r, so sboui starts the sboinstall/upgrade cli and interactively ask me if any options should be passed to the build and I can enter it at that point. However, after removing the -r, quitting sboui and restarting, then attempting a reinstall, sboui did NOT drop into basic cli process and did NOT allow me to interact with sboinstall after it deleted the package. Might be a new bug? OR Might be user error.....? So tried a second time and after making the change I hit enter to Apply changes which it acknowldeged, then quit, then started, but looked at the Options and the defaults are back to sboinstall -r and sboupgrade -r. When I deleted the -r again and applied, but didn't quit sboui, then ran keepassxc install it did drop me to the cli with interactive actions so I could answer the options question. Since I'm in root, what is overriding the option changes I made the first time making the -r persistent on each re-start?

I would like to suggest a feature enhancement. Would it be possible to develop a separate screen for package build options and add it under package "Actions" screen so the options can be entered and passed to the pkgtool? Right now the Actions screen has View README, (Install) Remove, Upgrade, Compute Build order, List inverse deps, and Browse Files. Browse Files allows me to see all the standard slackbuild files (including the README again). I like what is included, but wonder if you could add an item that would be Package Build Options. This might open a 256 character buffer line which would accept and capture input to pass to the slackbuild the same way any option can be passed when starting a slackbuild. Example, for keepassxc I can send "XC_HTTP=on ./keepassxc.SlackBuild" for a build and I have now got keepassxc to build with HTTP set ON. Since sboui is first executing the preferred tool (in my case sbotools) I'm not sure of when the options inputted would be passed, maybe just wait for sbotools standard question
"It looks like keepassxc has options; would you like to set any when the slackbuild is run? [n]"
and then respond with "y" and the option "XC_HTTP=ON" and another "Y" to "Procced with keepassxc? [y]

For now when I have options to pass I'll either modify the sboupgrade -r option or simply quit and run sboupgrade <package> directly.

If I was installing/upgrading multiple tagged packages, would it pass these global Install/Upgrade environment options to every package?

Cheers, Brian

Changes made in the Options window are only for the current session. If you want to change them permanently, you need to do it in the config file. If you want to change them for the current session only, change them in the Options window, but don't quit and restart again.

Also, please be careful about changing the default package manager settings. Using an option that causes the package manager to install dependencies will probably give weird results in sboui, because sboui handles dependencies itself and expects the package manager to install only the SlackBuild it requests. If you are using sbotools and you want to see the prompts, I'd recommend switching -r to -R instead of just removing -r.

The reason I have this as a global setting is because sboui asks you only once to select which dependencies to install. After making your selections, it goes ahead and makes all the changes you selected without pausing between each one, so there's no opportunity to specify build options individually for each one. The idea is that if you want to specify additional build options, you just allow them to be passed to everything that is being installed. The options will have no effect on SlackBuilds that do not recognize them. If you want to be sure to only apply the option to a single SlackBuild, simply select it for install (or upgrade, reinstall, etc.) twice. The first time, install only its dependencies. The second time, set build options in "Install (or Upgrade) environment vars" as desired, and then install the SlackBuild itself.

Having explained that, I can see how it would be more convenient to be able to specify environment variables that apply only to a specific SlackBuild and its dependencies directly in the actions or install dialog, instead of having to go back and forth between the main window and the options window. I'll give that some consideration.

Yes. But as I mentioned above, they would have no effect for any SlackBuild that did not include the option. For example, keepassxc is the only SlackBuild in the entire repository with an XC_HTTP option.

After giving it some thought, I think the best way to do this, within sboui's workflow, is to add a "Build options" parameter that applies to individual SlackBuilds and can be set from the Actions dialog. That way, the build options would be applied only for that SlackBuild (not its dependencies or other tagged SlackBuilds), and they would be remembered across all operations except syncing and, of course, closing the program. (Basically, what bamunds suggested, but not applying only to an immediately subsequent install or upgrade operation.) That certainly seems more natural and less of a hassle than using global environment variables for this task. What do you think about that?

Also, though I have written man pages for sboui and sboui.conf, I'm thinking it would be valuable to make a PDF user guide that explains each operation available in the UI. Not that I really like doing such things, but I probably should since most of the actual UI usage is not covered in the man pages.

montagdude, that would be great to see a Build Options per package. Let me know how I can help with the PDF manual development or further testing.
I wish this thread was getting more traffic from other testers.

If you're willing to help out with creating a manual, that would be awesome. You'd certainly get added as a contributor. I don't have a specific layout in mind, other than that I would like it to show screenshots of the different windows and dialogs and explain how to interact with each one and what each choice does. My plan is to use LaTeX and track the source file with git, but if you want to help and you don't know LaTeX, it would be okay to use something else to write it instead.

Sorry about the delay in my response. I'd be able to help with documentation/manual. I don't use LaTex but I'm familiar with layouts for newsletters, so adapting to LaTex shouldn't be that big of an issue. Where do you want to start?

I can create the LaTeX file with a rough outline and put it on Github. It might be best not to include too many screenshots, actually, because that makes updating the manual a pain. Anyway, we'll see where it goes. It's not needed right away.

In other news, I tagged version 0.3 on Github. I haven't updated it on SBo yet, but it is updated in my personal SlackBuilds git repo, so anyone can get it there for now. This release has lots of really useful new features. Here are the best ones:

• Added /etc/sboui/package_blacklist, where you can blacklist installed packages to prevent them from being upgraded, removed, or reinstalled. It works much like the slackpkg blacklist file, and it supports regex patterns. For example, "[0-9]+alien" will blacklist anything installed from Alien Bob's repository.
• "Quick search" function jumps to an entry in the active list while you type. Activate it with the Ctrl-s keyboard shortcut.
• Powerful new search option to search in READMEs instead of just names. This is really helpful if you don't already know the name of what you're looking for.
• Display a position notifier on the right side when scrolling.
• Set build options for individual SlackBuilds from the actions dialog instead of using the global install_vars and upgrade_vars.
• Smarter checks for whether things were actually installed/upgraded/reinstalled/removed as requested.

There were also a number of internal changes and some minor refactoring in this release. Hopefully I caught any regressions, but more people testing would be appreciated.

Just wondering if anyone has tried 0.3? I found some minor documentation things that needed to be fixed, so if there are no bugs or other things to change with the actual code I'll just tag 0.3.1 and update it on SBo.

I'll go and download and test this weekend, even though it is going to be very busy. Thanks for continuing to post! Cheers

sboui 0.3.1 has been released and will appear in the next public update of SBo. Compared to 0.3, there are just some minor documentation changes. There were a lot of really helpful enhancements relative to 0.2.1, though, which is the current version on SBo. So if you are upgrading from 0.2.1, you will see a big difference. The changes are listed in the ChangeLog, as always.

At this point, sboui does everything I wanted and much more, thanks to bamunds' input. Whenever we get the PDF user guide done, along with any other fixes or enhancements that may be brought up by then, I will mark it as version 1.0. I'm going to leave this thread open, though, because I still am welcoming anybody's comments, suggestions, and bug reports.

Wanted to report that I've loaded the 0.3.1 via sboui, filter upgradeable, install sboui and everything went almost as planned. I did not get prompted to check the sboui.conf.new, and even when I did a 'slackpkg install new' it did not pickup the "new' conf file. So I had to manual compare the working and .new and make appropriate changed for sbotools. Then everything seem to work as planned.

The new build options input line looks great, just what I was thinking it would look like. You've left the Additional Install CLO's and ENV variables in the global options screen, do they function the same as in the past? The new Show Package Info is also a neat add. I have not yet tried blacklisting. Will try to give that a go in the next week. The man page is looking good also. Thanks for all the great work

I don't think sbotools out sbopkg are designed to prompt you about new config files. Try `slackpkg new-config` next time.

Yes, install_vars and upgrade_vars still work the same way. For example, I use them to set MAKEFLAGS='j 4'. sbotools has a CLO to do the same thing, I believe.

[QUOTE=montagdude;5710130]I don't think sbotools out sbopkg are designed to prompt you about new config files. Try `slackpkg new-config` next time.

Oh, right, I'm not sure what I was thinking with slackpkg install new. When I ran slackpkg new-config it in fact pulled up the new config and prompted me for what to do. Since I had already modified it for sbotools and then copied it to sboui.conf I simply removed it this time. Thanks, Brian.

hi montagdude

your tool is great!

Can i make a feature request?
As your tool is very fast it would be cool if it could generate queue files as well.