Re: [Pkgutil-users] patch to support non-standard VERSION entries

[Peter B. <bon...@op...>]

On Mon, Jul 26, 2010 at 12:47 PM,  <ma...@pr...> wrote:
> Investigating support for non-CSW packages further, we could do with some more changes in pkgutil.  Presently, pkgutil will only ever look at the REV component of a VERSION string when determining which package is newer.  This is fine for CSW packages, where there is a standard that is strictly followed for the formatting of the VERSION string in pkginfo.  However, in order for us to support non-CSW packages in our internal repo, from a variety of third party vendors, we need to have a slightly looser interpretation of package version to cater for packages where the REV component is the sub-version (i.e. version takes precedence) or where the REV component is entirely missing.

I was kind of expecting that your small first patch would lead to
something like this. ;-)

What we at CSW have found is that it's more or less impossible to
compare unknown version strings and _know_ which one is newer, simply
due to not knowing which ruleset the author of that software used. Not
to mention when they all of a sudden change it.

That's why we decided to always add our own version, the REV-field, to
each package with a by us known content so we can easily and safely
decide what is newer.

> Here are some examples of what we needed:
>
> VERSION=5.0.8 is newer than VERSION=5.0.7
> VERSION=2.0,REV=16 is newer than VERSION=1.0,REV=18

Yes, those are easy because they can be numerically decided like our
REV-field. But how about 1.0 vs. 1.0b2? If the packages are from a 3rd
party and you're not willing to normalize the version you need to
handle everything possible and I guarantee someone will think of
something you didn't. :-)

> I've thought hard about how to support this in pkgutil without breaking CSW packages, and came to the conclusion that the best way was to add a new option in pkgutil.conf that would add this needed functionality, which by default would be switched off.

It would definitely be optional behavior. It must be isolated as much
as possible from the current behavior.

> While working on this, I also spotted and fixed a bug in the verscmp subroutine, where this check:
>        if (! $p2list[$i]) {
>          $update = 1;
>          last;
>        }
>
> Should have said:
>        if ($i >= scalar(@p2list)) {
>          $update = 1;
>          last;
>        }
>
> To avoid an error message about a non-initialised array element, and also to avoid the scenario where 5.0.8 would not be greater than 5.0.7 because of the zero in the second position.

Thanks, I will test this immediately. If this is good it will be in 2.1.

> By the way, I may have more suggested changes for you in the next few days.  When do you plan to release 2.1?

2.1 will go out shortly, it's feature frozen already. This is way to
big a patch to be included. But keep on coming with the requests. :-)

> I hope you get the patches ok and are happy to accept them.  I'm happy to discuss alternative solutions.

I will test them but I don't promise anything since I'm not really
happy about the growing non-CSW support. From the start I didn't
support it at all but more and more people asked for it. It does
complicate the code and increases the risk of bugs, especially since
the "unknown" factor is always there, what will people use it with
next?

How about adding a script to the pkgutilplus package that unpacks a a
package, adds a REV-field and repacks it again? ;-) Seriously, that's
simplified what a contributed script does today to make use of SUNW
packages possible. Earlier I got two separate huge patches to support
SUNW packages directly in pkgutil and they were very invasive and hard
to test so when this variant surfaced I included it immediately
because it doesn't change core pkgutil at all. It's all done
externally to make packages compliant before we use them in pkgutil. I
loved that. :-)

Just a thought.

-- 
/peter