package NAMING scheme
 

I could not find a document that would confirm this, though I did see many examples by various individuals that contradicted this. But I'm basically interested in what is used by Slackware and maybe SBo. My purpose is so I can make a tool that will translate a package name with a version to a package name without a version, for matching a version-less reference.

The base version-less package name may have any number of "-" characters separating parts of the name. A version string is constructed that does not include any "-" characters. It is appended to the name separated by "-", followed by some kind of sequence number (what is this called, "packaging version"), also separated by "-".

I have seen package names with as many as 4 "-" separated parts before the version number, such as "font-adobe-utopia-100dpi".

So the following awk command could input the full versioned name and output the version-less name:
Is this correct or do I need to know more about this than I figured so far?

Try using regular expressions instead of parsing the string with bare hands.

If you google for slackware package naming convention, this is the top hit. http://www.slackware.com/~mozes/docs...esentation.pdf
Is this what you mean?

If I'm understanding this correctly, you're trying to get just the package name (or package name with version)?

I don't know a whole lot of awk, so I use this (for package name only):
So if I wanted a list of installed packages without their version name:
Personally I'm not a huge fan of the whole: `rev | cut | rev' thing but I haven't figured out a way to do it without rev in shell so I've stuck with it.

If you want package names with version, you just need to change the field list to "3-" so it looks like:
You can of course, use the one with the package name and a version, then just take off the version with another `cut' probably.

I could not figure out such an expression for this.

Why reinvent the wheel? Just have a look at functions package_base() and package_name() in /sbin/{install,remove,upgrade}pkg ;)

ERRATUM read pkgbase(), not package_base()

Actually, the "whole" 'rev | cut | rev' thing makes sense. For me "rev" just wasn't in my mental toolkit so I never thought to try it (I don't think I've ever used it for anything). I guess my background of lots of "by hand" parsing in C bent my mind in the direction of doing it "by hand" in shell with awk.

I was focused more on "is this really the naming scheme" (my google search just didn't come up with anything, perhaps because I did not use the term "convention"), rather than "how could one parse this" (I have no trouble with that ... I just do it by hand).

I didn't see "package_base()" in there. I did see "pkgbase()" but it's just removing the extension (not something I need ... at least not yet).

I did see "package_name()" but it seems to be more complex and I don't really follow it. Can the name scheme be described in English? (or French or German or Norwegian is OK)

If you are using bash, then simply:
PKG=full-name-version-arch-build #(with or without *.txz)
echo NAME=${PKG%-*-*-*}
You are correct, the separator is the '-' character and fields should be viewed from right to left. In other words, if you have a version number(or arch or build) with a '-' in them, then installpkg will be confused. Names can have any number of '-' chars in them as you like.

Here is PART of what I am going to be doing with this. I want a search mechanism where an exact package can be found, rather than a prefix (that would be tempting but for what I'm doing would cause problems). If I did a prefix type search then "sysvinit" could match all of "sysvinit-2.88dsf-i486-3.txz" and "sysvinit-functions-8.53-i486-2.txz" and "sysvinit-scripts-2.0-noarch-15.txz". But I really want "sysvinit" to match "
sysvinit-2.88dsf-i486-3.txz". To get "sysvinit-functions-8.53-i486-2.txz" then "sysvinit-functions" should be used. This is because of the way I am building a list of packages that will be used to select package files for installation (it will also allow specifying the package with the version).

I don't need help on how this will be done. I was just looking for confirmation of the name scheme, that the last 3 parts separated by "-" are not part of the name itself.

At this point in my code development I'm taking the full file name and coming up with just the versionless name. See my awk script. See the "rev|cut|rev" method it seems most everyone else uses. Do you have something that would be better?

Here it is as a possible regex:

EDIT: P.S. I checked and it gives the same result as the earlier command with rev:

This is what I use in one of my scripts. It generates a list of available packages using the following approach
The output is formatted into 3 fields: base package name, versioned package name and the full filepath of the package on disk.

If you want to look-up a specific package it's just a case of tightening the grep using the appropriate anchors.

You need to store all candidates in an array, and loop through them until you find the package you want.
A simple example to illustrate it:

This is very close to what I want to do. But this is going to be something that repeats the search for all packages from a given list. So my idea is to generate the list that maps the non-version basename and version basename to full path just once and store that in a file. Then I can run grep to do the search ... many times.

I may end up re-writing my code from Bash to Python. That will change things quite a bit. Then it will be easy to have the entire list of packages in a dictionary indexed by version and non-version base names giving full path.

I took a sequential approach using sorted input rather than go down that route. My script (it's a system update aid akin to slackpkg but with a different approach) offloads most the gruntwork to join, comm, and sort.

0.157s elapsed to compare the packages installed on my system to those available on my local mirrors. Can't be bad.
Originally I used only bash internals to manipulate the data (along the lines of the example gnashley made earlier) and it was much slower than sorting and using join, comm and such.

I briefly considered recoding it in perl but what I have works so well I couldn't really see the point and it's nice having runtime requirements that are only bash + coreutils.

Really, rev|cut|rev?, awk?? python??? What could be simpler than:

+1. And this should work with any POSIX compliant shell.

Yep, gnashley's approach is what I normally use in these situations. Bash isn't very efficient when running these sort of manipulations but unless you're processing vast amounts of data it won't really matter.

Here's two different approaches to what I was doing above
As you can see, the sed version is much faster and uses less cpu -- though neither are slow enough for it to matter for such a small amount of input data. The reason I used sed in my script was because it was already using 'join','comm' and 'sort' so having an external dependency on sed really didn't make much difference ( plus it was a bit of an experiment ;) ).

P.S. Of course, the bash version is infinitely more readable than the sed/regex. :D

Wrong post, didn't read the question right.

"bash version is infinitely more readable than the sed/regex" in this case by a lot! But often it is the other way around.

Indeed. But this was a new one for me. Glad you guys jumped in with it.

This one, found in pkgtool and copyright Patrick Volkerding, maybe hard to read but is super fast!