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
Attachment:
signature.asc
Description: OpenPGP digital signature
_______________________________________________ CentOS mailing list CentOS@xxxxxxxxxx http://lists.centos.org/mailman/listinfo/centos
