Re: Patch to add install action to packages:

[David Douthitt]

Phil D'Amore wrote:
> On Thu, 2005-03-03 at 06:14, David Douthitt wrote:
>
> > Phil D'Amore wrote:
> >
> > > On Tue, 2005-03-01 at 14:10, David Douthitt wrote:

> You could not use class predicates inside classes:.  IIRC that is not an
> issue anymore, but it was a limitation at the time.
>
> Additionally, given the situation where you have a number of args to
> each item like pkgmgr/action/version/whatever, I find the action syntax
> more pleasing to the eye, but that is just my opinion there :).

It becomes clearer....

> 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.

> 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.... ;-)

>  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.  Consider too, TeX, which used pi 
for a version number, increasing in precision with each new version. 
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?

> You are referring to Mark's comments about his experience with RPM?  I
> don't think it is certain that the implementations of RPM are different
> there.  The output he was posting to the list leads me to think they are
> the same.  Two bugs were recently found in RPMCheckPackage() which may
> have caused this, and I submitted a patch to fix it to the bug list. 
> Once Mark has time to test again we will know for sure.

I do know one thing for sure - having worked with RPM on Red Hat, SUSE, 
and Mandrake, I believe I can state authoritatively that the program RPM 
is _not_ the same on each.  In particular, I believe that RPM on SUSE is 
a heavily patched rpm 3.x, whereas Red Hat uses the current 4.2 (or 
whatever latest).  Mandrake I believe has patches; certainly they got 
into trouble for repackaging source archives with bzip2 wherever possible.

> > 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?

--
David Douthitt
UNIX System Administrator
Linux+, LPIC-1, RHCE
HP-UX, Unixware, Linux, FreeBSD, OpenBSD
Member: ACM, USENIX/SAGE