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>