[csw-maintainers] cswclassutils: location of template init scripts

[Maciej (Matchek) Blizinski]

No dia 22 de Junho de 2010 19:34, Philip Brown <phil at bolthole.com> escreveu:
> Maciej, you seem to wish to go down the pedantic path. So okay, lets
> get pedantic :-)

Me, pedantic?  Since when?  ;-)

> On Mon, Jun 21, 2010 at 4:40 AM, Maciej (Matchek) Blizinski
> <maciej at opencsw.org> wrote:
>> No dia 16 de Junho de 2010 18:38, Philip Brown <phil at bolthole.com> escreveu:
>>> On Wed, Jun 16, 2010 at 10:26 AM, Maciej (Matchek) Blizinski
>>> <maciej at opencsw.org> wrote:
>>>> ...  The definition of CAS
>>>> is that they handle the installation of files, with potential
>>>> additional processing.  Having CAS process other files is something
>>>> that CAS isn't intended for.  I know that you can hack it, but it
>>>> might cross the fine line between use and abuse.
>>>
>>>....
>>
>> Your two above paragraphs sound as if you thought that I'm questioning
>> the use of classutils, which I'm not.  I'm saying that classutils are
>> designed to process given lists of files.
>
> http://docs.sun.com/app/docs/doc/806-7008/6jftmsc38?a=view
>
> "Object classes allow a series of actions to be performed on a group
> of package objects at installation or removal."
>
> This is ambiguous. It doesnt say that renaming the objects, or
> duplicating, or removing, objects, is either explicitly allowed, or
> explicitly denied. It merely says "actions", on "objects" with the
> only limitation that the objects be associated with the package.
>
>
> My view of this is:
>  Since the entire purpose of system standard utilities such as
> "installf" and "removef", are to DYNAMICALLY create and remove files
> associated with the package.... files that, **by definition**, are not
> in the initial prototype/pkgmap file... then the ambiguity is strongly
> resolved in favor of "it is allowed.".
>
>
>
>
>
>>  Even though you could write
>> a CAS that processes additional files under certain circumstances
>> (empty input), I think this is a bad idea, because:
>>
>> 1. It relies on undocumented behavior which might change (CAS being
>> called with empty input vs CAS not being called at all)
>
> Actually, it is *explicitly documented* behaviour.
>
> again, from the above url:
>
> "Note –
>
> Even if there are no regular files of this class anywhere in the
> package, the class action script will be called at least once with an
> empty list and the ENDOFCLASS argument.
> "

*drumroll*
/me is convinced

Cool, if it's documented, I only see minor reasons why not do it that
way, so the balance shifts towards the solution you propose.  If it's
implemented in a sane way and documented on our end, it should be
okay.  The above link should be added to the source in a comments
section, for future reference.

Maciej