[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Patch to add install action to packages:
From: |
David Douthitt |
Subject: |
Re: Patch to add install action to packages: |
Date: |
Thu, 03 Mar 2005 15:05:22 -0600 |
User-agent: |
Mozilla Thunderbird 1.0 (Macintosh/20050120) |
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
- Re: Patch to add install action to packages:, David Douthitt, 2005/03/01
- Re: Patch to add install action to packages:, Phil D'Amore, 2005/03/01
- Re: Patch to add install action to packages:, David Douthitt, 2005/03/03
- Re: Patch to add install action to packages:, rader, 2005/03/03
- Re: Patch to add install action to packages:, Phil D'Amore, 2005/03/03
- Re: Patch to add install action to packages:,
David Douthitt <=
- Re: Patch to add install action to packages:, Tim Nelson, 2005/03/03
- Re: Patch to add install action to packages:, rader, 2005/03/03
- Re: Patch to add install action to packages:, Phil D'Amore, 2005/03/04
- Re: Patch to add install action to packages:, Jim Wight, 2005/03/04
- Re: Patch to add install action to packages:, rader, 2005/03/04