Re: Patch to add install action to packages:

[Phil D'Amore]

On Thu, 2005-03-03 at 20:53, rader@ginseng.hep.wisc.edu wrote:
>  > >>> The evidence of such trouble is evident already in a much simpler area:
>  > >>> recognizing operating system versions and releases.  HP-UX 11 had this
>  > >>> problem, and the numerous various Linux distributions render this 
> almost
>  > >>> impossible to keep up with.  Does cfengine recognize White Box Linux? 
>  > >>> TinySofa? Enguarde? Vine? Miracle? Red Flag?  And most importantly, can
>  > >>> it be made to recognize these variants without recompiling?
> 
>  > >> Agreed, 100% with you on that one.  The magic string file method would
>  > >> probably be a workable solution there, then folks would only have to
>  > >> download the latest magic string file to be updated.  They could even
>  > >> distribute that through cfengine as well via update.conf.  I still think
>  > >> there'd have to be some level of detection in code to at least determine
>  > >> the OS type (Linux, HP-UX, Solaris), since those are reliably obtainable
>  > >> with uname(), but once that was known, a magic string check could
>  > >> probably be applied to find specifically what you are dealing with.
> 
> I think you're confusing the detection of OSs (names and kernel
> revs via uname) with Linux distributions here.

Actually no I'm not confusing them.  What I did here was misremember how
cfengine did Linux distro detection.  I thought it said, "oh, this is a
Linux host, now let me go see what kind", using uname() for the "oh this
is a Linux host" part.  After going back to RTFS, I realize it does not
do that.Iit just looks for one of the files like /etc/redhat-release and
defines the classes based on what it finds there, regardless of the host
OS.

> 
> Cfengine already has OS detection via "uname", "uname -r" and
> the like.
> 
> Kernel info (uname) doesn't work for detecting Linux distros:
> different distros can have the same kernel names and versions
> (eg Scientific Linux and RHEL.)
> 
>  > > Perhaps the module previously put up for Scientific Linux would work in a
>  > > more general fashion?
> 
> Of course.
>   
>  >    I'd be in favour, but I don't know how others would feel about 
>  > perl :).
> 
> Keep in mind that the classes my module defines won't work in
> all places.  For example, it doesn't work in the "files:" section.
> I haven't really investigated this peculiarity; I assume files:
> gets evaluated before modules do.

I like modules.  I use modules.  However, for this application,
something so basic to cfengine's functionality, I think a module would
be yucky.  Yes, that's a technical term.  Bolting on a <insert favorite
script language here> script to the cfengine distro does not seem like
the way to go.  Besides, classes from modules only get defined after you
use them, so the class won't be defined for the entire time the agent is
running.  Also, you might also run into nastiness where AddInstallable
would need to pre-declare all possible classes since if you didn't,
parse-time optimizations might optimize out anything relying on a class
your module defines.

On top of that, don't you need to pre-declare the classes that a module
returns?  Perhaps that restriction is gone from current versions.

Writing a small bit of relatively generic C code into cfengine to read
an easily modifiable text file that is distributed with cfengine,
containing the patterns, and their resulting classes, would probably be
the way to go here.

> 
> steve 
> - - - 
> systems & network manager
> high energy physics
> university of wisconsin
> 
> 
> 
> _______________________________________________
> Help-cfengine mailing list
> Help-cfengine@gnu.org
> http://lists.gnu.org/mailman/listinfo/help-cfengine
-- 
Phil D'Amore                             "Sometimes there is a fine line
Senior System Administrator               between criminally abusive
Red Hat, Inc                              behavior and fun."
Office: 919.754.3700 x44395                 -- Ted the Generic Guy
Pager: 877.383.8795                            (Dilbert 4/19/2003)