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

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

>> # pkgutil -i vcs -S 5.0MP3
>>
>> for example, where our magic -S option (--select) tells pkgutil that
>> you know there are multiple entries for the catalogue name 'vcs',
>> the one you want is the one where the VERSION/REV string contains
>> the text '5.0MP3'.
> 
> This would require a dependency-mechanism not depending on a package name, but a specific version of
> a package (e.g. derived from the catalogname). Only considering matching packages won't work in
> specific environments - Veritas prior to 3.5 comes to my mind where you had a match
> vcs 2.0 - vxvm 3.2 - vxfs 3.4
> In the catalog-approach you would bundle all of these in one catalog and everything would be fine.

Not quite "everything fine".  Ok, say you've got 10 software stacks to maintain on a single box.  Each software stack has an average of 5 different versions.  Any given box can have any combination of different versions of the software stacks.  How do you expect to manage re-pointing pkgutil to 50 different repos depending on which software stack you wish to manage on a particular day?  And then, if you're editing pkgutil.conf to do it, what if you're in a department of 30 sysadmins all of whom could be editing that file at any given time without your knowledge?  Then add puppet into the mix.  This is a recipe for trouble.

pkgutil is designed to handle package dependencies.  I understand this was the original purpose for developing the tool.  With dependencies comes the issue of managing software stacks.  By definition, pkgutil ought to have an elegant solution to this problem.

> Hand-tailoring the catalog would be very tedious here. IMHO having a drop-box folder for packages
> with as much automation as possible is favored as opposed to a manually crafted catalog.

Agreed.  Whatever the solution is, it'll need to do as much automatically as possible, only prompting the user where a choice really has to be made.  Perhaps we could seed it with information collected from an existing system where the full software stack is already installed?  This would be feasible.  Existing CSW repos would continue to behave as they always have done, as there would be no choice to make (if you wanted to stick with different catalogue names and package names for different versions of software, as you currently do on CSW, that wouldn't change).

btw did I not recently submit a patch to bldcat to auto-generate the catalogue name?  Without that patch you have to hand-tailor your SysV packages which is hardly the automation approach that you are subscribing to.

> A hacker is someone who abuses a tool for things it were never meant to do,
> not someone who puts a spoiler to a car to go faster. To me it looks
> the existing functionality in pkgutil is already capable of what you want to do,
> but you want to do it differently.

Disagree.  I'd like to see pkgutil mature into a more powerful tool that can be used in large-scale enterprise environments.  It is not quite there yet, but it's not far off.  This is what I said to Peter yesterday, pkgutil is so close to being able to manage non-CSW packages extremely well, is it not better to make the necessary changes to improve the product, as long as we do so wisely and carefully (and definitely not by "hacking" anything), rather than by starting again from scratch?

Earlier we spoke about a mapping file, let me suggest:

#
# /etc/opt/csw/pkgutil.map
#
# Mapping file used by pkgutil and bldcat for identifying non-standard
# packages and assigning them a catalogue name and version string
# in the pkgutil catalogue
#
#package "parameters" common-name version
VRTSvcs "VERSION=5.0|PSTAMP=Veritas-5.0MP3RP2-07/07/09-11:27:00" vcs 5.0MP3RP2,REV=2009.07.07
VRTSllt "VERSION=5.0|PSTAMP=Veritas-5.0MP3RP2-07/07/09-11:27:00" llt 5.0MP3RP2,REV=2009.07.07
VRTSgab "VERSION=5.0|PSTAMP=Veritas-5.0MP3RP2-07/07/09-11:27:00" gab 5.0MP3RP2,REV=2009.07.07
VRTSperl "VERSION=5.8.8.0|PSTAMP=5.8.8.0 05012007" vperl 5.0,REV=2007.01.05

As suggested earlier, a file like this could be automatically generated if run on a system that already had the software stack installed.

Thoughts?

Best regards,
Mark.