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

[Dagobert M. <da...@op...>]

Hi Mark,

Am 27.07.2010 um 13:36 schrieb ma...@pr...:
>>> The other issue I'm going to be looking into shortly is that of
>>> supporting multiple versions of the same package.
>>
>> Usually you use different catalogs for this and then use overlays in
>> pkgutil.conf on all these, e.g.
>> veritas41/
>> veritas50/
>> veritas51/
>
> Yes that's feasible.  Managing lots of different repos is a bit of a  
> headache though, don't you think, particularly the more software  
> stacks you have to maintain?  Also, does it not make the command- 
> line rather long?  Each time you run pkgutil you'd have to use the - 
> t option to specify a different repo, e.g.
>
> # pkgutil -t https://swrepo.mydomain.net/sw/current/veritas5.0 -i vcs
> # pkgutil -t https://swrepo.mydomain.net/sw/current/veritas5.1 -i vcs

I would have configured that statically in the local pkgutil.conf

> vs. doing it in a single repo with different catalogue names, e.g.
>
> # pkgutil -i vcs50
> # pkgutil -i vcs51
>
> But two problems with this.  1 - can't auto-generate the catalogue  
> name (re my earlier bldcat patch) if the catalogue name has to be  
> unique.  2 - the catalogue file uses package names in the dependency  
> list, which won't be unique, and should be modified to use something  
> that will be unique (such as the package filename).

Yes. Yes.

> We would need a radical fix to this, take a deep breath, here goes:
>
> The catalogue name can no longer be a unique identifier.  The  
> package filename must become the unique identifier.
>
> Phew, radical stuff.  I think I need to lie down.
>
> So then your instructions for sysadmins never change, the latest  
> version of VCS available in the production repo is always installed  
> by 'pkgutil -i vcs'.  But in addition, you might be able to type:
>
> # 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.
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.

> We could be more radical still.  Yes we could.  We could allow  
> package filenames to contain directory names, so that we could  
> organise our repo more logically.  So we could have your
>
> veritas41/
> veritas50/
> veritas51/
>
> subdirectories in the repo if we chose, and the catalogue filename  
> would contain the subdirectory name as well.  One catalogue,  
> multiple subdirectories.  The end-user is oblivious to the fact that  
> when he says 'pkgutil -i vcs' that it is downloaded from a  
> subdirectory.
>
> How open is everyone to being radical with pkgutil? :-)

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.


Best regards

   -- Dago