Feature #2370

OpenBSD package provider could be a little more robust

Added by Joe McDonagh almost 3 years ago. Updated almost 2 years ago.

Status:Closed Start date:06/29/2009
Priority:Normal Due date:
Assignee:Joe McDonagh % Done:

0%

Category:package
Target version:2.6.0
Affected Puppet version:0.25.4 Branch:http://github.com/mmrobins/puppet/tree/feature/master/2370-open_bsd_package_version
Keywords:openbsd package
Votes: 1

Description

The provider for OBSD packages is pretty brute- it complains it’s not versionable, yet OpenBSD packages usually take the form of ${PACKAGENAME}–${VERSION}, so if I try to ensure something like ‘screen’ is installed it fails because I need to specify the version inside the package name. Alternatively, there could be a parameter such as force, that installs each package there. I’m going to guess this is a ‘needs design decision’ type of ticket.

2370.patch (3.9 kB) Joe McDonagh, 06/30/2010 07:16 pm

History

Updated by James Turnbull almost 3 years ago

  • Category set to package
  • Status changed from Unreviewed to Accepted

Updated by James Turnbull almost 3 years ago

  • Target version set to 4

Updated by Joe McDonagh almost 2 years ago

  • Affected Puppet version changed from 0.24.8 to 0.25.4

The provider also has problems where it thinks some packages are not installed so it tries to install them again. That’s probably a separate but related issue.

Part of the problem is at line 19 where the regex is defined for matching up package names, ensure values, and ‘descriptions’. Since descriptions are useless (a string that describes what a package does is not a part of the resource) it should be discarded. Next, it must be taken into account that some packages beyond versions have what OBSD calls ‘flavors’. So for example, screen comes in an shm and static flavor. So the package looks like this:

screen-4.0.3p1-shm

or

screen-4.0.3p1-static

or

screen-4.0.3p1

To confuse things even more, some package names can have a – in them, so the – isn’t always a valid separator. I can’t think of a good way to handle this, but I am going to take more of a crack at creating a patch, possibly tonight if time permits. In the meantime, if anyone has a suggestion for a regex that would handle the four aforementioned cases, feel free to update the ticket with it. Everything I’ve tried so far fails for certain cases.

Updated by Alan Barrett almost 2 years ago

Before OpenBSD added “flavors”, it used to be the case that the last hyphen separated the package name from the version number; the name could contain embedded hyphens but the version could not. I don’t know whether they allow multiple flavours to be appended, but I’ll assume that they do, and that appended flavours can be differentiated from version numbers by whether or not they begin with a digit; so, I assume that, of all the hyphen-separated components, the last one that begins with a digit is the version number. I think this regular expression should store the name, version, and flavour (with hyphen prefix), in $1, $2, and $3:

^(.*)-(\d[^-]*)((?:-\D[^-]*)*)$

Updated by James Turnbull almost 2 years ago

  • Status changed from Accepted to In Topic Branch Pending Review
  • Assignee set to Joe McDonagh
  • Target version changed from 4 to 2.6.0

Joe – any chance you can test the new regex?

Updated by Uwe Stuehler almost 2 years ago

FYI: The “official” documentation for OpenBSD package names is the man page OpenBSD::PackageName(3p), which follows the more general packages specification in packages-specs(7). The reference implementation to look at would be the functions splitname() or from_string() in /usr/libdata/perl5/OpenBSD/PackageName.pm.

from_string() uses the following Perl regular expression: /(.?)-(\d.)$/o (/o has no semantic meaning relevant to the discussion.) This splits the package name into a “stem” and a “rest”, which is the version number and all flavors (yes, there can be multiple). The first hyphen separates the version number from the first flavor, additional hyphens separate the flavors from each other.

When forming a package name from the raw constituents $stem, $version and @flavors, the flavors are sorted in alphabetical order and then joined, together with the stem and version, using a single hypen as the separator between each constituent.

I hope that helps someone.

Cheers for working on it, Uwe

Updated by Alan Barrett almost 2 years ago

Uwe Stuehler wrote:

FYI: The “official” documentation for OpenBSD package names is the man page OpenBSD::PackageName(3p)

Thanks. I don’t use OpenBSD, and failed to find that in a web search.

from_string() uses the following Perl regular expression: /(.?)-(\d.)$/o

This regular expression treats the first hyphen-separated component that begins with a digit as the version number; the regular expression that I gave in comment 4 above treats the last such component as the version number. The difference becomes apparent only when a flavour name begins with a digit, or when a portion of the base package name begins with a digit, and either of those seems unlikely to happen, but changing “.” to “.?” near the beginning of the regular expression in comment 4 would make it consistent with the documented behaviour of from_string().

Updated by Joe McDonagh almost 2 years ago

Sorry been busy- just saw this, will test as soon as I can.

Updated by Joe McDonagh almost 2 years ago

Patch attached, probably could be more efficient but seems to work for flavored and non-flavored packages via the flavor parameter.

Updated by Matt Robinson almost 2 years ago

  • Status changed from In Topic Branch Pending Review to Ready For Checkin
  • Keywords set to openbsd package
  • Branch set to http://github.com/mmrobins/puppet/tree/feature/master/2370-open_bsd_package_version

Hey Joe, The patch looks good. I managed to run this on an OpenBSD virtual machine and install a specific version and flavor of a package.

It would be nice if this had tests. I realize that you may not be familiar with rspec, and it’s more important that this work for people using OpenBSD than it is that it’s thoroughly tested, but if you had a chance and could add tests, perhaps based on the tests of one of the other package providers, that would be awesome.

Markus, I’ve put this code in a branch on this ticket. The branch is based off master, so it may at some point need to be backported to 0.25.x.

Matt

Updated by Markus Roberts almost 2 years ago

  • Status changed from Ready For Checkin to Closed

in Master as commit:6ac36eb42f0a505fd37d7e600bb0fd8837511b42

Updated by James Turnbull almost 2 years ago

In 0.25.x as commit:ad386c2e5ce45ece3a7ac0965d155ab23fe32e23.

Also available in: Atom PDF