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

[Sebastian Kayser]

Philip Brown wrote on 18.12.2009 22:22:
> On Fri, Dec 18, 2009 at 12:54 PM, Sebastian Kayser <skayser at opencsw.org> wrote:
>>
>> Couldn't we simply ship pkgutil/pkg-get with a admin(4) file that
>> suppresses CAS warnings and then call pkgadd with it per default?
> 
> I would guess you mean "suppress postinstall scripts" warnings.

No, I specifically meant suppress CAS warnings. Please see below.

>> Then we could have:
>>
>> - cswclassutils: Eventually move from /usr to /opt/csw/somewhere.
>>  While not all been packages have been converted, maintain the
>>  CAS twice for /usr and /opt/csw/somewhere.
> 
> I thought of this when I first proposed the class action script
> approach, years ago now. However... have you tested whether class action
> scripts WORK anywhere other than /usr/sadm/blah, if they are not in
> the same package? As far as I recall, they do not. They must be
> in either /usr/blah, or in each individual package that uses it.

Correct. My thought was to add _CAS stubs_ for required functionality to
our packages. These would be added by GAR and do nothing more than
something similar to

	exec /opt/csw/somewhere/{i,r}.cswfoo

plus some logic for Jumpstart and zone environments where
/opt/csw/somewhere is /$someprefix/opt/csw/somewhere. So our whole suite
of CAS would be centrally maintained at /opt/csw/somewhere.

Combined with the admin file to suppress CAS prompts (for the CAS stubs
in the package) this would free us from /usr and not incur any
additional prompts to the user.

> Thus, there are TWO major benefits to our existing classactions scripts:
> 
> 1. user doesnt get prompted about routine boring stuff from a postinstall script
> 
> 2. There is a COMMON utility across all our packages, deployed to a
> SINGLE place.
> This means that if we update a class action script, we update it ONE
> time,and all packages get the benefit.
> The alternative, would mean that, if we bundled class action scripts
> individually in every package that used them... then every time we
> find, "oh dear, there's a bug in [classactionscriptfoo]", we would
> need to repackage and release EVERY PACKAGE that used it!!

With the suggested approach, the main intelligence is kept in
/opt/csw/somewhere. The CAS bundled with the packages are simple stubs
so that the likelihood of bugs in these stubs is minimized. Still, you
are right, if there were a bug in one of these stubs each dependent pkg
would need to be repackaged (not rebuilt).

> I will propose an alternative, that came to me today while pondering
> this problem. An alternative, would be for us to publish our own
> version of the SVR4 pkg utils. This version would respect class action
> scripts elsewhere, such as /opt/csw/[whereever]. [...] I imagine it
> would be a considerable effort for someone to do this. Allegedly,
> the source is out there somewhere... but you'd have to track it down
> and make it useable.

Sounds like a substantial effort to deliver/maintain and honestly, I as
a sysadmin would not be willing to install 3rd party repackaged pkg*
tools which directly deal with my package database.

Currently, I am not sure whether either options is a viable one.

Sebastian