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)
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.
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.
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.
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.
Kind regards,
-- dag wieers, dag@xxxxxxxxxx, http://dag.wieers.com/ --
[all I want is a warm bed and a kind word and unlimited power]
