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

[Maciej (Matchek) Blizinski]

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.
>
> I disagree. Sun has used it in this way for years. almost a decade? one of the
> "standard, documented(but often ignored)" ways, used it in this sort of way.
> the cron, sed, or awk class I think. dont remember which.

There are i.awk and i.sed action scripts, but none of them processes
files or locations outside the given list.

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.  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)
2. It makes the whole solution harder to debug

> by definition, the  sun cron class is an example of, "take one file,
> and use a CAS to modify another file (crontab)"

Yes, and let CAS stay this way.

>> Perhaps CAS are not the right way to solve this problem?  If you just
>> want to run a script upon package installation, this is what pre- and
>> postinstall are for.
>
> but "just run a script" is not the full design goal. the full design goal is,
> "and not bug users about prompts for 'do you wish to allow this
> unknown script to run?' for common , known, shared framework scripts,
> while at the same time STILL prompting (if the user desires) for truly
> unknown one-shot scripts"
>
> The CAS scripts  may eventually be shared by hundreds of our packages.
> The site admin should be able to evaluate the safety of the script(s)
> one time, and then have trust in them.
> The CAS approach allows this. The regular postinstall script approach does not.

The way of shipping the script is a separate issue from script
contents.  The trust you're bringing up has to do with the script
contents, while the discussion above is about the way of shipping.

>>> I also dont understand the purpose of the column labeled,
>>> "No modification to cswinitsmf (no bugs)"
>>
>> The purpose is similar to other criterion columns: point out any flaws
>> in described approaches.  What is the specific issue with this column?
>
>
> let me rephrase: I dont understand the column :)

There are 2 issues in 2 columns: one is whether you need to modify the
script at all (and potentially introduce bugs).  The other is whether
the introduced change will make the script harder to debug.