On Tue, 2006-04-25 at 13:26 +0200, Dag Wieers wrote:
> On Mon, 24 Apr 2006, Les Mikesell wrote:
>
> > On Mon, 2006-04-24 at 05:39, Dag Wieers wrote:
> > > >
> > > > There's a bugzilla entry concerning that (which I cannot find anymore at
> > > > the moment), but it didn't look like RH wanted to change that.
> > >
> > > Correct, I would have to replace perl. That's why I don't :)
> >
> > I thought perl could be perfectly happy with multiple versions
> > living on the same machine as long as you keep your paths
> > straight. There should be no need to replace the existing
> > one to install something newer.
>
> Sure, I can make a package that adds the same version (or a newer version)
> of perl available alongside the current one. Would it be advisable ? No.
>
>
> > > > So I don't think that this is a yum bug, this is a bug in RedHat's perl
> > > > packaging, as you are not able to override modules which are included
> > > > with the core perl package. And that hasn't change up to FC5.
> > >
> > > It's a bug in Yum that it does not consider the previous amavisd-new. Apt
> > > and smart would do that. This allows me to provide a newer amavisd-new for
> > > those people that do provide a newer perl-Digest-MD5 (there are multiple
> > > ways you can fix the dependencies and run amavisd-new).
> >
> > It is an unrealistic expectation in both RPM and yum that you
> > won't ever need to run multiple versions of some programs on
> > the same machine at the same time. Is this the first time
> > you've seen this problem? Pretty much every developer that
> > needs a stable version working while he tests the next one
> > should have run into it.
>
> I guess I wasn't clear the second time in explaining what the problem is.
> So here I will add another example:
>
> User wants to install amavisd-new.
> Repository has amavisd-new 2.3.3 and 2.4.0.
> Package amavisd-new 2.4.0 has a missing dependency (unless you replace a core package)
>
Nothing is stopping them from having the error, understanding the issue
and doing this in their yum.conf:
exclude=amavisd-new-2.4.0
Then ... yum should resolve the depenancies
> Yum will fail to work as it will only consider version 2.4.0 in resolving
> dependencies. Apt and smart will correctly install the latest package.
>
Actually ... Apt and smart are smart enough to install the older
package .... which is maybe good, and maybe not.
I would think that if I see no errors that I have the latest
packages ... which I don't (I have amavisd-new-2.3.3 and not 2.4.0 ...
so I don't even know there is a problem unless I happen to see it is not
the version that I think it should be).
> According to the Yum developers this situation is a repository problem.
> But I disagree, I should be able to provide packages (like version 2.4.0)
> to people that are able to fix the dependencies manually without blocking
> _all_ other users.
>
If they exclude the new package because they can't solve the
dependencies, then they can upgrade ... and they know they have a
problem.
People who want the older packages to automatically install can use
either apt or smartpm ... if they really want to.
BTW ... this is not really a repo problem or a yum problem ... it is the
supplier of the software who choose to not support RHEL. They really
should support RHEL with their products if they want it used in the
business world. That is my opinion, but I could be wrong :)
> There are other advantages to provide newer packages that are
> uninstallable (by default) as people then tend to understand that the
> problem is related to upstream (either Red Hat or amavisd-new developers).
>
> Also, other repositories might wish to choose to offer a perl replacement
> package, unlocking the situation for amavisd-new 2.4.0. So the argument
> that the repository has a problem is a fallacy and is only true if you
> consider a repository to be self-consistent. And the _only_
> self-consistent repository there is, is the original OS repository.
>
That is true. Other people might offer another upgrade ... at which
time you can remove that package from your exclude.
All the good yum stuff I talked about works w/ version 2.4.x ... version
2.0.x is not so fully featured. We are looking into using a yum 2.4.x
w/centos3 as well, if it is possible (python version issues need to be
worked out for that).
>
> Now, regarding your statement about installing 2 programs alongside each
> other. Often programs don't even work if they are installed together and
> there is little need for normal users to have multiple versions (except in
> certain cases). Besides, developers seldom use RPMs for simply testing
> their applications.
>
> Besides that, RPM does allow different versions to be installed at the
> same time, using the same rules as allowing 2 different editors to be
> installed at the same time. It's just a discussion about semantics.
Dag, you know that CentOS appreciates all that you do, and the 3rd party
repo thing is not at all meant to insinuate that your repo is anything
other than top notch ... I use it on every single computer that I
admin :)
I also would not recommend that someone add the CentOSPlus repo or the
CentOS-Testing repo and run "yum update" without using
includepkgs="the_stuff_they_want" either ... as it will update core
packages and can cause issues too.
Thanks,
Johnny Hughes
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.centos.org/pipermail/centos/attachments/20060425/3dd76b0b/attachment.bin
