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

[<ma...@pr...>]

 On Mon 26/07/10  2:01 PM , Peter Bonivart bon...@op... sent:
> I was kind of expecting that your small first patch would lead to
> something like this. ;-)

Give an inch, I'll take a mile ... I was just warming up :-)

> 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.

Understood we might not catch 100% of cases, but if we can catch 98% of cases, the outlying 2% can be treated as exceptions.  1.0 vs. 1.0b2 would actually still work given the patch I presented you, because the b would be stripped leaving 1.0 vs. 1.02.  What wouldn't have worked was 1.0 vs. 1.0b.  But I have yet to find an example like this from one of our vendors (all the examples I can find will work with the patch I sent you).

> How about adding a script to the pkgutilplus package that unpacks a
> package, adds a REV-field and repacks it again? ;-) 

As Dago says with pkgedit, it's easy to do this.  However, we don't want to get into vendor support entanglement.  This is our issue.  If we start modifying third party packages just to get them working in our repo, the vendor could - quite rightly - turn round and say "then we don't support you because you've tinkered with our software".  Because pkgutil is so close to working with non-tampered packages, it's much easier to modify pkgutil to get it right than it is to start from scratch and write another version of pkgutil all over again that does almost everything the same.  If, as I have done, that functionality is kept cleanly separated so that it does not interfere with CSW support.

Dago's suggestion of a separate mapfile is also a good idea, where the comparison logic can be fine tuned, although expecting this to be done for every non-CSW package is onerous.  Start with good built-in logic that works for 98% of cases, then use a mapfile to clean up the exceptions.

I realise pkgutil was originally only written for CSW, but I believe there is a gain to be had in building in full non-CSW support so a wider audience can realise its benefits.  It's a great tool that plugs a sizeable gap in Solaris package management.

The other issue I'm going to be looking into shortly is that of supporting multiple versions of the same package.  At the moment, and correct me if I'm wrong, pkgutil expects catalogue names to be unique.  So the only way to support multiple versions in the same catalogue is to tweak the catalogue name.  In fact a prime example, already in opencsw.org, is GCC, where you can request gcc2, gcc3 or gcc4.  There are other examples on opencsw.org.  In a large corporation, where there are always different versions of software stacks on the go at the same time, it would be easier if the software could be addressed using the same catalogue name, but where a specific version could be requested on the command-line.  This is further complicated by the fact that the dependencies in the catalogue use package names - so dependencies on particular versions can only be specified if the package names differ too.  Have you ever considered improving this?

I'm happy to continue to send you patches for a variety of improvements to the tool, and I am as keen as you are to keep the tool easy to maintain and fully CSW compatible.  I have more time I can devote to this over the next few weeks.

Can I check, is bldcat GPLed?  It didn't say so in the comment at the top of the script.

Thanks,
Mark.