Re: Patch to add install action to packages:

[Tim Nelson]

On Thu, 3 Mar 2005, David Douthitt wrote:

> > Plus, like it or not, if the overall interface changed now, it'd
> > probably break a lot of people.  We can change the guts if that's what
> > people want, but I'd really like to see the main part of the interface
> > stay the same, even if a few variables have to change/die in the name of
> > science or progress or something noble like that.
>
> Believe it or not (given my ranting) I am a STRONG believer in not breaking 
> things as they stand..... Like you said, it would break a lot of people. 
> Better to have a switch to "turn on" new features in some fashion.

	I think you can break things between major versions, if you gain 
enough :).  So cfengine 3 (in my opinion) could change stuff.  Again 
IMHO, editfiles needs a serious rework, and in spite of having to rewrite 
a chunk of my config, I think *that* change would be worth it :).

> > But, I cannot ask rpm directly to tell me if gcc is
> > installed, say, at a version equal to *or* greater than a specified
> > version.  That'd be a really nice feature, though.
>
> Ah, but APT can.... ;-)

	Both Yum and up2date come with libraries that have functions that 
do this.  Even I should be able to make a program that does this.

	After further investiagtion, there's a C lib called "rpmlib" which 
also does this.

> >  When I'm using
> > version comparison, which honestly isn't very often, I tend to want
> > that.  I'm willing to bet there are other package managers out there
> > with the same limitation.
>
> As I understand it, version checking is quite nasty.  Consider SmallEiffel, 
> which until recently used negative version numbers that increased, 
> approaching towards zero.

	I'm not even sure that you could get RPM to do negative numbers 
:).  But once you got it to do them, it'd be no more complex than any 
other.  Do you have any idea how they dealt with it?

> Consider too, TeX, which used pi for a version 
> number, increasing in precision with each new version.

        Why is that hard?  Each version is greater than the last.

> Not to mention that 
> SmallEiffel became SmartEiffel and changed its version number to a more 
> standard one beginning with 1.0.  Sigh.  What's next?

	The standard approach would be to rename the package, and do 
something with "provides" and "conflicts", or something.

> > > 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.
>
> Perhaps the module previously put up for Scientific Linux would work in a 
> more general fashion?

	I'd be in favour, but I don't know how others would feel about 
perl :).

--
Tim Nelson
Server Administrator
WebAlive Technologies Global
Level 1 Innovation Building, Digital Harbour
1010 LaTrobe Street
Docklands, Melbourne, 
Vic, 3008
Phone: +61 3 9934 0812
Fax: +61 3 9934 0899
E-mail: tim.nelson@webalive.biz
http://www.webalive.biz/

"Your Business, Your Web, Your Control"