|
From: | Tim Nelson |
Subject: | Re: Patch to add install action to packages: |
Date: | Fri, 4 Mar 2005 12:08:07 +1100 (EST) |
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 StreetDocklands, 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"
[Prev in Thread] | Current Thread | [Next in Thread] |