[suggest] Re: suggest Digest, Vol 53, Issue 2
nkadel at gmail.com
Wed Nov 4 15:06:27 CET 2009
> From: Christoph Maser <cmr at financial.com>
> Subject: Re: [suggest] Re: suggest Digest, Vol 53, Issue 1
>> Careful: When I tried personally updating to cfengine 3.x last summer,
>> I found the format different enough to be incompatible with my
>> existing CFengine layout. And since CFengine is used to edit system
>> files, it's important to be *really careful* updating it.
>> Perhaps it should be released as 'cfengine3' at RPMforge? This would
>> have prevented some of the problems I had with other packages, like
>> Nagios, when it updated as well.
> I really don't like those renamed packages like apache2 and cfengine3,
> they add extra code in the spec file and the name is just wrong. Maybe
> there is another sane way to specify "do not upgrade from version <= 3"
> in the specfile? Negative requires?
I understand your concern, but this is a familiar problem with
packages like apache (which was renamed httpd as part of the switch to
the new 2.0 codebase) and mod_perl (whose naming conventions and
compatibilities and dependencies became insane before the 2.x release
because of its links to apache), and sqlite, and Berkeley db
(published as db2, db3, db4, etc.), and openssl libraries which are
publiahsed as openssl097, openssl096, etc. because they're not
backwards compatible and upgrading a live system will *break* it,
really seriously. In theory, a "yum update" should provide safe
updates and leave you a working system. Breaking CFengine under people
who rely on it for broadly based systems management, especially for
systems that are not RPM based, would be.... well, it would be bad.
I've not seen anything in the .spec files that will block this sort of
upgrade: blacking an upgrade of the package of the same name would
break the RHEL 5 yum-cron and yum-updatesd used to keep packages up to
date on a regular basis.
More information about the users