[CentOS] sa-update error with perl

[Johnny Hughes]

On 01/11/2012 04:42 AM, David Hrbáč wrote:
> Dne 11.1.2012 1:13, email builder napsal(a):
>> Well, kind of.  If you review this thread, you'll see that the the fix
>> was to stop using the RepoForge package for perl-NetAddr-IP so that it
>> wasn't mixed with CentOS packages for perl-Net-DNS and
>> perl-IO-Socket-INET6. Maybe your position is that you won't fix
>> perl-NetAddr-IP because you only support it when used when all other
>> packages are from RepoForge, but I don't think that's realistic at all
>> - everyone running CentOS will have mostly CentOS packages -
>> naturally.  They'll pick up some others they want or need for various
>> reasons from RepoForge, so I'd imagine you'll see mixing of packages
>> quite often amongst people who add RepoForge to their yum systems. 
>> Therefore, I'd have thought you'd be interested to learn of an
>> incompatibility in one of the RepoForge packages.
> Well,
> I will definitely not fix it. Most of users does not pick up the
> particular packages but enables the repo entity. Basically it would be
> really hard to support both scenarios. I consider packages you mention 
> as a whole email stack provided by RF. The stack includes:
> amavisd-new
> spamassassin
> dependent perl-\*
> dependent file de-compressors
> Regards,
> DH
I agree with David here ...

repoforge has moved all packages that replace CentOS base packages to
their rfx (repoforge extras) repository.

If you are going to use rfx packages, you likely need to use all
relevant rfx packages and not mix and match (which is what caused this
problem). In this case, that would include the whole stack for
spamassassin. This DOES replace base CentOS packages ... but that is the
purpose of the RFX repo, so don't enable it in the first place if you
don't want to replace CentOS packages. And if you DO want to replace
CentOS packages, then replace them all for the things you are installing
from rfx.

A different way to accomplish the same thing without replacing CentOS
base packages (if your goal is to prevent replacing base packages ...
which may or may not be your goal) is to first try EPEL. EPEL has a
version of amavisd-new (for this particular scenario) which works
properly with all the base CentOS packages. A goal of EPEL is that they
can not replace packages from RHEL (so also not CentOS). But the version
of amavisd-new is older in EPEL than the one in RFX. Which is best ...
that is up to you.

I am not recommending one approach over the other ... which approach you
take depends on your goals. Most of the time my personal goals are to
stay as close to the enterprise OS as I possibly can and only replace
packages if absolutely necessary, so I would likely try EPEL first and
go to RFX later. But, I do not know of any packages in RFX that break
things, so I think either approach can be equally "stable" on CentOS
servers.

The bottom line is that you need to understand what you are trying to
accomplish and adjust your strategy as necessary. You need to understand
what the goals of a repository is before you enable it (does it replace
base packages, do I want to try to block that aspect of the repo, etc)
... and you need to enable it correctly if you intend to use it.

For RFX (as an example)... if you enable things like yum-priorities
(which will always choose base/updates from CentOS over newer packages
from RFX), that is going to cause issues where some packages from RFX
may not work properly with the base CentOS packages.

Adding 3rd party repos is complicated and if you do it, you need to pay
close attention to what each one does and enable it properly. You can't
expect 3rd party repos to support using only parts of the repo and not
others (ie, yum-priorities) ... but you also can't expect CentOS to
support the packages installed by the 3rd party repos that replace base
packages. Therefore, YOU have to support yourself if you add them :D

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 262 bytes
Desc: OpenPGP digital signature
URL: <http://lists.centos.org/pipermail/centos/attachments/20120111/faf9d0ea/attachment.sig>