[csw-maintainers] CSWcswclassutils: it wants to write in /usr

[Philip Brown]

On Tue, Dec 22, 2009 at 2:28 PM, Gary Law <glaw at opencsw.org> wrote:
>
> I have to say the number of installations with shared nfs /opt/csw
> would -- I guess -- be far fewer than the number with zones with read
> only /usr.

The problem set isnt "all zones that have read only /usr".
The problem set is "all zones that have read only /usr, AND the
sysadmin is unwilling/unable to update it".  Which is a much smaller
set. I would guess comparable in size to the
"nfs shared, or otherwise replicated /opt/csw".

Rupert, for one, counts as a thousand installs of the "otherwise
replicated /opt/csw" case ;-)

But anyways, moving on to some implementation details...


>> if we provide an alternative CSWcswclassutils package, whose function
>> is, "go run actions that normally get done at pkgadd time", then we
>> could cover the very small amount of people who are "blocked" by our
>> regular version of the package deploying to /usr.
>>
>> This would be an ALTERNATIVE to our regular  package, rather than replacing it.
>
> That gets my vote if there's a way to handle the dependencies.


sure, no problem.
The "alternative" package, would be outside the regular catalog, but
have the exact same name.
So things would work as follows:

regular catalog offers CSWcswclassutils, REV=2009.12.23
"alternative" download url/catalog, offers the "alternative
workaround" package, that is ALSO NAMED, "CSWcswclassutils,
REV=2009.12.23".

Neither pkg-get nor pkgutil do any fancy checks about point of origin,
of an already installed package.

So, installing "lftp", the util would say to itself, "Hmm. this
program need CSWcswclassutils. My catalog says I need REV=2009.12.23
of that.    Checking current installed version.... version number
matches. Ok, moving on..."

no problem.

We just need to keep updates of cswclassutils infrequent, to avoid
inconveniencing the manual updaters.