Didier, when will the official documents be updated to reflect your explanation? Also the slack wiki is showing the same language as the official Slackware Documentation page. It is obvious that someone decided to break away from the official standard and why montagdude needs to be cognisant of the difference when he writes the code to ignore the "bad" usage of dashes, which is why I pointed this out in my post. Hopefully the exception code can handle reading from the right.

There's nothing wrong with those package names. Like I said, they must have at least four words separated by dashes. The problem with yours was that they had less than four.

Well, I've never used those tools, so I'm not sure whether they are always supposed to produce valid package names automatically or how much of that is up to the user. If you can reproduce the invalid package names using those tools, it might be worth opening a new thread about that to figure out for sure how to avoid the problem in the future.

Yes, that link has it correct. Package names should have the form: app-version-arch-tag

None of the four components can contain dashes, except for the app portion. As for testing compliance, sboui-0.2.1 (when it's released) will give you warnings about any that are invalid.

Excellent!

The reason is that version 0.1.1 used a shell script to query the list of installed packages, whereas now it's handled in C++. Compiled languages are faster but have the possibility to segfault if they try to access a memory location that doesn't exist. In this case, it happened to you because the C++ code I wrote assumes that each package has at least four words separated by dashes. If it's actually less than four, it will end up trying to access an invalid memory location. The shell script method would have just returned empty strings instead, but not attempted to access any invalid memory location.

The warnings about unused variables are expected. Actually, the fact that you saw them means that you compiled it successfully with the debug flags as intended. The only question is whether that debug sboui version was actually installed after you built it. Based on the output you posted, it looked like the old, non-debug version was still installed. If you want to try again, change the BUILD variable in the SlackBuild script from 1 to 2. Then, you can check the entry for sboui in /var/log/packages after installing and make sure it ends with -2_mntg instead of -1_mntg.

Either way is fine.

I can't say exactly, but maybe this weekend or early next week.

Actually the official document description says it must be four parts, no at-least in what is written. It also doesn't say that the app name can contain dashes. Instead dashes are delimiters between the four parts and underscrore is to be used to link words within the parts. Which is why I'm wondering if anyone is going to update what is written to clarify dashes are allowed in the app part?

I'll check the documentation and then contact the original developers to ask for any clarification.

Done, as a standard Release and everything is working fine.

Great thanks.

This is just semantics. The package filename does have to have four parts, the name, the version, the arch, and the build tag. As others have said, it just uses dashes as delimiters and counts from the right to left. This is why it's important to not have dashes mixed into other locations, because it can screw with the package manager. If we use your previous example of sddm where you had a dash in the tag, we can use some color to better illustrate how the package manager views things.

app-name-version-arch-tag
sddm-0.12.0-x86_64-1alien-SBo

So, as you can see, the package manager would think the name of this program is sddm-0.12.0, with the version being x86_64.

If we look at two examples of the package names with not enough dashes, it sees the following.

XnViewMP-linux-0.83.x64
brave-0.13.0.x86_64
brave-0.13.5.x86_64
skypeforlinux-64

As you can now see, the package manager can't even assign these packages a name, and most wouldn't have a version assigned. This is why it was able to have brave installed twice, because upgradepkg can't find a package name to upgrade.

SlackDocs does specifically state that dashes are not to be used in the VERSION string, but it doesn't mention that the app name can't have dashes... although, if you're not familiar with how the package manager works, I could see that causing confusion. But you can always look at official packages to see how it's done there. Several official Slackware packages names contain dashes -- and when I say several, there's 401 packages out of 1332, or 30%, that contain at least one dash in their name in Slackware 14.2 (and just for fun... 226 have at least 2 dashes (17%), and 10 have 3 dashes (0.7%) and there aren't any that contain 4 or more dashes).

But if you feel it should be better specified, it is a wiki that once registered, you're able to edit as well. And even though it is hosted on a subdomain of slackware.com, it doesn't mean it is official documentation. Anyone is free to write an article and add it there (I wrote an article on how to use UUIDs in your lilo and fstab, but it certainly isn't anything official). So, while it may be hosted on an official Slackware server (not sure if it is hosted on the Slackware server or just using the subdomain and being hosted somewhere else), it might not be considered "official documentation". If you're not comfortable with your editing skills, there is a discussion tab that allows you to make suggestions for someone else to incorporate.

1 members found this post helpful.

@bassmadrigal I really appreciate the example and clarification that you continue to provide to those learning the Slackware way. While my package names were not compliant with the package description, installpkg and upgradepkg both allowed me to install the packages, and allowed me to install more than one package of an application, so I could run either as desired from the command line with specific name rather than a link to only "brave". I've read the documents and the "slackware-way" for installing packages and I'm wondering if why they aren't complete on this subject, so I'll pursue the comment as you've suggested.

Perhaps someone could further help educate me on naming generation. Does anyone know why the three rpm binary packages converted using the "official" rpm2targz package builder didn't get the proper naming?

I call it an "official" package because it is installed in every default installation, and it is specifically mention in the Slackware Esssentials, Slackware Wiki, and documentation link from slackware.com under Package installation. I know that it is an ageless package which has existed in Slackware for over 15 years. Is it maintained still?

I read on many LQ threads that rpm2targz is a packager of last resort if one can't find an "unofficial" Slackbuild or build from source. I've even read that gnashley's src2pkg is a better tool, however when using it, it too doesn't generate the package naming convention as seen in my XnView package name, unless one forces the options (yes I also RTFM and the Tutorials/Examples). Slackbuilds doesn't even mention the naming convention to use for creating a slackbuild script. I've always looked for packages in the following order:
1) packages.slackware.com (extra directory has some nice ones)
2) slackbuilds,
3) rpm binaries on OpenSuSe (seems they are best quality for rpm2targz )
4) debian packages and then convert with src2pkg
5) straight source to config/make/make install (I've actually only done this once and it failed after installpkg).

I'm sure many senior member experts here would have number 5) as number 2). The question is which will produce the more compliant "slackware-way" package in both name and file system placement rpm2targz or src2pkg? (Sorry gnashley I'm not trying to bash your package, the documentation is excellent, the tool is complex, the results are mixed compared to packages converted with rpm2targz.)

Thanks, and again I'll head over to the documentation project to request clarity in on naming conventions.

bassmadrigal,

iirc, a slackware package is being read backwards, therefore you can have dashes in the name, but not in the version. Also, the tag is separated by a _ not a -

Personally, my order is as follows:

1. Official Slackware packages
2. SBo
3. Eric's packages
4. Create my own SlackBuiild
4.1. Prefer building from source
4.2. If source isn't available, I'll manually extract the package's contents and repackage them into a Slackware package. (That's what I did with discord.)

I haven't used rpm2tgz or deb2tgz in quite a few years, mainly because I was running into similar issues to what you're seeing now. I haven't used src2pkg in a much longer period of time.

I'm not sure if {rpm,deb}2tgz take into account package names. They might just use what's already there rather than verifying it is a proper name. I know I wouldn't want to code something to figure that out, especially if the original rpms or debs can come with broken names. But to know that, someone would have to dig through the scripts to see how the handle it.

That is correct. The example I used above was from a broken package name that bamunds provided earlier in the thread. There was a dash in the tag separating 1alien from SBo rather than an underscore, so it threw off the parsing of the package name.

@montagdude, sorry for derailing your thread

montagdude, I also must apologize for derailing your thread about the sboui tool. I will only post with input about the tool going forward.
Please post when the next release is available.
Should I do any cleanup of the /var/log/packages earlier posts to compact this thread?

It's okay, it was mostly related to the topic anyway. But I would say any further discussion of how src2pkg and rpm2tgz name packages should go in its own thread.

sboui-0.2.1 has been released on Github. This release is mostly to fix bugs and improve robustness. Here are the changes:

• Don't warn about skipping dependencies unless actually installing the package
• Actually close .info file in ShellReader::close() (woops! but had no noticeable effect in use)
• Check for and warn about invalid installed package names (previously would segfault)
• Check for and warn about missing .info files when encountered
• Better check for upgradable pacakges. A package is considered upgradable if installed_version != upgradable_version, except when the only difference is a trailing tag starting with an underscore in installed_version (some packages for kernel modules are like this). Previously, anything after the available_version text was considered a tag, even if it didn't begin with an underscore.
• Restore original selection after pressing Esc in ComboBoxes.

It will be available on SBo next time they update the site (usually towards the end of the week). Or, you can get the SlackBuild from my Github page if you want to try it out right away.

About testing for upgradable packages, I wouldn't mind having some discussion about that. The only way to make sure a package is marked as upgradable is to do a strict test for whether installed_version = available_version. The problem with that is that some SlackBuilds append a tag to the version string during install. For example, virtualbox-kernel appends "_${uname -r}" to the version number, so a strict installed_version = available_version test would always mark it as upgradable even if it's really at the latest version. The test I am using now (described above in the list) is the best way I can think of to do it, but it is possible for it to miss something that should be marked upgradable in some unusual circumstances.

montagdude, tonight I tried to upgrade sboui from within sboui. Is that supported? The results first show that a package is being upgraded from a different repository and asks to proceed (nice little touch) then it showed the package installed (and I like the little popup screen that says Packages failed/installed/etc). The only problem was when I checked /var/log/packages it still reported that sboui-0.2 was installed and not sboui-0.2.1. I sync'd again and then look for Upgradeable packages sboui again shows up for upgrade. Tried and second time and got same results as first.

I thought I'd try a sbotools cli upgrade to make sure it wasn't a sbotools shortfall. Sboupgrade sboui says: libconfig (libconfig-1.5-x86_64-1_SBo) is already installed.
sboui (sboui-0.2-x86_64-2_mntg) is already installed. If I attempt to sboinstall sboui-0.2.1 is says "Unable to locate sboui-0.2.1 in the SlackBuilds.org tree" However I confirmed at slackbuilds.org that sboui-0.2.1 is in the tree. What I found was that I had to removepkg the local slackbuild package (found in /tmp) and then sboinstall sboui to get the latest version sboui-0.2.1 to install. It was like it wouldn't upgrade something that doesn't have an SBo tag. However, I also have alienbob's version of ffmpeg installed (same version number as in slackbuilds.org), and when I attempted to re-install (since version number wouldn't show in an upgrade list) it it had no problem removing the existing package, building new and installing. So perhaps this is an "upgrade" only issue?

Having used the tool for a while it is a huge assistance to use over the cli of sbotools. It offers a great way for users to to keep their slackbuilds up to date.

There are some additional improvements I'd like to suggest. First, when showing the packages for upgrade, you show in the lower screen the Installed and Available versions, but only the version number and not the build number, it might be helpful (like with the sboui which was a local build) to know that I am replacing a local build with an slackbuild (assuming that actually is possible and works). After an upgrade the slack-desc are not presented to the user, that might be a nice option on that "Failed/Installed/etc" screen to offer to see the "Read Readme" again so that any last minute instructions not included in the info file are seen now from the Slack-Desc file. Another nice touch would be if I could see the last screen of install for a package, in (this case I'm thinking the Package Description, Executing Install, Cleaning) as an option on that "installed" list of options. I suggest the last because if I select any other "Readme or View Files" as I'm flipped to text viewer I see that last set of console outputs and thought that would be nice to have seen that before or option to see when I'm taken back to the install/upgrade screen of sboui.

Really enjoying the program. Thank you developing it and hope my feedback is helpful. Cheers, Brian

Yes, it is, but you will need to quit and start it again to for the changes to take effect.

I've noticed something like this before with sbotools, but I need to do some more testing to find out what exactly it is doing. I think the "sboupgrade" command may not work with packages installed from a different repository. The reinstall operation would have worked, because sboui first removes the package and then installs again with the reinstall operation.

Anyway, I do have a plan to deal with these little quirks of the different tools. In the next version, sboui will first try the regular upgrade command, but then it will check to make sure it was actually upgraded by comparing the installed version with the version available in the SBo repo. If it wasn't upgraded, but there wasn't an error during the operation (like an MD5 mismatch), it will use the reinstall method to upgrade it instead.

There are already a couple new features in the development branch to help with this. The first is an action presented when you select an entry in the list called "Show package info," which will display the name, available version, whether it is installed, and for installed packages, the installed version and complete package name. The second is a package blacklist. It works more or less the same way as the blacklist for slackpkg, except that it operates only on installed packages, so it prevents upgrade/remove/reinstalling but not installing in the first place. You can use regex patterns to make sure packages with a specific build/tag are not changed.

I might be able to make it so the actions list is re-displayed after the operation is complete. I'll look into it.

Would a keyboard shortcut that drops to a view of the command line output do the job you're describing?

I'm glad you like it, and I really appreciate your feedback and suggestions.

Great, thought as much and had tried quitting to run ls /var/log/packages | grep sboui. That's when I found the issue.
are you finding it with sbopkg or other tool?
Great ideas.
Yes it would.

Keep up the great work!

It doesn't happen with sbopkg, because sbopkg doesn't have a separate upgrade option. You just use the regular install option, which builds and installs the package with `upgradepkg --reinstall --install-new`. Installs, reinstalls, and upgrades are all taken care of naturally with that command. sbotools uses the same upgradepkg command, but it also checks first to see if the package is upgradable. It appears that the check does not detect packages installed from places other than SBo. Whether that's intentional or not, I'm not sure.

I just attempted to use sboui to upgrade keepassxc and realized that there is no way to insert options. sbotools progresses by asking about building dependencies and also if there are any options to insert. Keepassxc allows for XC_HTTP=ON and XC_AUTO_TYPE=OFF, but with sboui there is no place that was obvious to setup these options and pass to sboupgrade. So I dropped out to cli and ran the upgrade from there. Did I miss something about entering options for the building of packages?