Problem with slackpkg and package names that are four segments long

[chrisretusn]

There is a problem with slackpkg and package names that are four segments long. When issuing the command 'slackpkg info' with a package that has four segments for a package name you get the following result:

# slackpkg info font-adobe-utopia-75dpi

No packages found! Try:

        slackpkg search 'font-adobe-utopia-75dpi'

and choose one (and ONLY one package).

My proposed fix is:

--- /usr/libexec/slackpkg/cutpkg.awk.org	2023-04-20 23:21:59.872739781 +0800
+++ /usr/libexec/slackpkg/cutpkg.awk	2023-04-20 23:25:34.446733411 +0800
@@ -1,6 +1,6 @@
 OFS="-" { 
-	if ( NF > 3 ) { 
-		NF=NF-3
+	if ( NF > 4 ) { 
+		NF=NF-4
 	}
 }
 1

The result is:

# slackpkg info font-adobe-utopia-75dpi

PACKAGE NAME:  font-adobe-utopia-75dpi-1.0.5-noarch-1.txz
PACKAGE LOCATION:  ./slackware64/x
PACKAGE SIZE (compressed):  1196 K
PACKAGE SIZE (uncompressed):  1430 K
PACKAGE DESCRIPTION:
font-adobe-utopia-75dpi: font-adobe-utopia-75dpi (bitmap fonts for X11)
font-adobe-utopia-75dpi:
font-adobe-utopia-75dpi: font-adobe-utopia-75dpi is part of X11.
font-adobe-utopia-75dpi:
font-adobe-utopia-75dpi: For more information about the X.Org Foundation (the providers of the
font-adobe-utopia-75dpi: X.Org implementation of the X Window System), see their website:
font-adobe-utopia-75dpi:
font-adobe-utopia-75dpi: http://www.x.org
font-adobe-utopia-75dpi:

I posted this over at the forum also:
https://www.linuxquestions.org/questions/slackware-14/slackpkg-2-84-0_beta1-testing-wanted-4175643527/page19.html#post6425946

[opty77]

Fortunately no package names with five segments:

opty@vodopnik:~$ wget -q -O - https://ftp.linux.cz/pub/linux/slackware/slackware64-current/CHECKSUMS.md5 | grep -v '/source/' | grep -E '\.t.z$' | rev | cut -d \/ -f 1 | cut -d - -f 4- | rev | grep -E '([^-]+-){4}' | wc -l
0

[chrisretusn]

Of course not, that would not be a properly formatted Slackware package file name.

[alienbob]

Of course not, that would not be a properly formatted Slackware package file name.

A package basename can have infinite segments. The last three segments in a package filename are VERSION, ARCH and BUILD but for instance this is an existing package with five segments in its basename: "gst-plugins-bad-free-compat32".

[alienbob]

I also think this is not a bug. The argument you need to supply after "slackpkg info" is the PACKAGE name, see "man slackpkg". What you supply instead is a package basename, not the full package name.
The reply you get from slackpkg when you type your original command is all you need to get your result. First run "slackpkg search" followed by that basename; you will get one or more full packagenames back and then you pick exactly one of these results and use that as the argument to "slackpkg info".

FYI the function of cutpkg.awk is to find the basename of a package name. It strips the final three segments from the packagename, being VERSION, ARCH and BUILD, to obtain the package's basename. The fact that it needs to make that distinction is because ancient Slackware package filenames did not always adhere to this package naming convention we are so used to, and may have less than four segments.

[chrisretusn]

Of course not, that would not be a properly formatted Slackware package file name.

A package basename can have infinite segments. The last three segments in a package filename are VERSION, ARCH and BUILD but for instance this is an existing package with five segments in its basename: "gst-plugins-bad-free-compat32".

Okay I stand corrected on basename. Makes sense. Learned something today.

[chrisretusn]

I disagree on not a bug. If the intent is based on requiring the full package name, then the bug is that a three segments or less base name passed to 'slackpkg info' works. It shouldn't. If a full package name is needed then it should fail in all instances except when a full package name is used.

With some further investigation, my "fix" is not a fix anyway, it breaks 'slackpkg upgrade', as cutpkg() is used.

Yes, cutpkg() with cutpkg.awk strips the last three segments only if the number of fields is greater than 3, so a base name passed with three segments works with 'slackpkg info'. This is why my "fix" worked with 'slackpkg info'.

If a three segment base name works then why shouldn't 4 or more work too.

The awk stanza in the "info" option of slackpkg uses the base name returned by cutpkg() to search PACKAGES.TXT. It will work with any base name regardless of the number of segments. The issue is what cutpkg() returns for NAME. In the case of "gst-plugins-bad-free-compat32" it returns "gst-plugins" with that plugged in to the awk stanza the search fails because it's looking for "gst-plugins-version-arch-build" in PACKAGES.TXT; which does not exist. If the five segment base name is used for NAME the search succeeds. The awk stanza doesn't care what the rest of the package name is, only that it is version-arch-build

[alienbob]

I disagree on not a bug. If the intent is based on requiring the full package name, then the bug is that a three segments or less base name passed to 'slackpkg info' works. It shouldn't. If a full package name is needed then it should fail in all instances except when a full package name is used.

Like I said: slackpkg needs to make that distinction (less than 4 segments versus all other names) because ancient Slackware package filenames did not always adhere to the contemporary package naming convention we are so used to, and may have less than four segments. Slackpkg tries to support these ancient Slackware package filenames (take a peek at https://slackware.uk/slackware/slackware-8.0/slakware/a1/ for instance). Whether this kind of support is actually still relevant is questionable of course.
Therefore I still think this is not a bug, "slackpkg info" requires a package filename, not a package basename.
However, removing support for Slackware < 9 and expecting that a Slackware package filename adheres to contemporary conventions is a feature request that would make sense.

[piterpunk]

As @alienbob wrote, the issue related here is not a bug. slackpkg info works flawlessly with packages with four or more segments in its name:

$ /usr/sbin/slackpkg info font-adobe-utopia-75dpi-1.0.5-noarch-1

PACKAGE NAME:  font-adobe-utopia-75dpi-1.0.5-noarch-1.txz
PACKAGE LOCATION:  ./slackware64/x
PACKAGE SIZE (compressed):  1196 K
PACKAGE SIZE (uncompressed):  1430 K
PACKAGE DESCRIPTION:
font-adobe-utopia-75dpi: font-adobe-utopia-75dpi (bitmap fonts for X11)
font-adobe-utopia-75dpi:
font-adobe-utopia-75dpi: font-adobe-utopia-75dpi is part of X11.
font-adobe-utopia-75dpi:
font-adobe-utopia-75dpi: For more information about the X.Org Foundation (the providers of the
font-adobe-utopia-75dpi: X.Org implementation of the X Window System), see their website:
font-adobe-utopia-75dpi:
font-adobe-utopia-75dpi: http://www.x.org
font-adobe-utopia-75dpi:

I disagree on not a bug. If the intent is based on requiring the full package name, then the bug is that a three segments or less base name passed to 'slackpkg info' works. It shouldn't. If a full package name is needed then it should fail in all instances except when a full package name is used.

...
Therefore I still think this is not a bug, "slackpkg info" requires a package filename, not a package basename. However, removing support for Slackware < 9 and expecting that a Slackware package filename adheres to contemporary conventions is a feature request that would make sense.

Probably this is a good move. I guess that anyone using Slackware < 9 isn't using new Slackpkg versions. Removing the support for old package names in slackpkg info seems simple and without collateral effects. The same change in other sections of Slackpkg needs more attention and time to think.

[chrisretusn]

Packages from less than 8.1 will not work with slackpkg (8.3 names ), I have verified this with slackpkg 15.0, not confirmed with lower versions. I now agree that, based on the man page that a package name is required. Yet it also works with basenames of three or less. It does not work with basenames of four or more. The working with three or less in my opinion is a flaw (a bug).

That said, I think most folks who use slackpkg use the basename for most options including 'slackpkg info' On top of that I doubt that 'slackpkg info' is as frequently used as with the other options.

I discovered this by chance while checking a local package with four basename segments. In Slackware-current there are 39 out of 1602 packages with basenames of four. Multilib has 48, with 6 having a basenames of five out of 259. I was one local package with a basename of four out of 166. That's not a lot.

So call it what you want. A bug, not a bug, a feature request. Fact is if "package" is required then the user should get a message stating this when attempting to use just the basename with 'slackpkg' info.

Two possible solutions, modify the code to give a message unless a package is used. The second would be to allow for basenames of any size to be used. My proposed patch to slackpkg.

--- /usr/sbin/slackpkg.orig	2023-04-25 13:31:49.552641965 +0800
+++ /usr/sbin/slackpkg	2023-04-25 13:51:09.599607524 +0800
@@ -512,7 +512,11 @@
 	;;
 	info)
 		PATTERN=$(echo $ARG | sed -e 's/\+/\\\+/g' -e 's/\./\\\./g')
-		NAME=$(cutpkg $PATTERN)
+		if [[ $ARG =~ [^-]+-(${ARCH}|fw|noarch)-[^-]+ ]]; then
+          NAME=$(cutpkg $PATTERN)
+        else
+          NAME=$ARG
+        fi
 		awk -F: "/PACKAGE NAME:.* ${NAME}-[^-]+-(${ARCH}|fw|noarch)-[^-]+/,/^$/ {
                                 found=1
 				 if (\$1 ~ /"$NAME"/) {

Since slackpkg+ handles 'slackpkg info' separately, it will also need patching to work this way.