[CentOS] sa-update error with perl

Wed Jan 11 15:33:51 UTC 2012
Johnny Hughes <johnny at centos.org>

On 01/11/2012 08:42 AM, email builder wrote:
>>>>  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.
> I don't 100% understand your explanation of EPEL, but I'm definitely
> going to go learn about it.
>
>> 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
>
> I understand this in principle, but I think reality ends up being a
> little more difficult.  I think I ended up with what RepoForge packages
> I did because at the time I built the server, CentOS either didn't
> have amavisd-new at all or RepoForge's was newer and without
> knowing about yum-priorities, I got the RepoForge one (and a bunch
> of other dependencies) without really understanding the implications
> (I had enabled RepoForge to get a version of Postfix that wasn't
> horribly crippled, although at this point both RepoForge and CentOS's
> versions of postfix are deplorably ancient - compiling by hand may
> be in order).
>
> So I could have been better educated for sure, but the way it plays
> out also isn't going to be straight forward in a lot of cases I think.
> Maybe RepoForge should make it more clear on their site what the
> implications of using their packages are or that users may want to
> use yum-priorities for a better chance of avoiding problems.  I
> certainly would have thought twice if their site had warned me of
> possible problems that could happen if I was only using part of
> their whole "email stack".
>
> And then there's the problem Nicolas is pointing out, which seems
> to be part of my problem.  If such conflicting packages are supposed
> to be in rfx but are not.....    Maybe Daniel could move it, which 
> would definitely help my yum to stop complaining....
> _______________________________________________

It is now part of RFX and not part of RF.  If you look here, you will
see no perl-NetAddr-IP now in RF.

http://apt.sw.be/redhat/el6/en/x86_64/

(there is a repoforge and and extras dir under there)


-------------- 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/dc512b54/attachment-0005.sig>