>>> 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....
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
http://lists.centos.org/mailman/listinfo/centos
