On 4/25/06, Dag Wieers dag@wieers.com wrote:
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.
I'd much rather have a 2nd copy of just about anything than a non-standard modification to a distribution file. When that gets too unwieldy, it's time for a new distribution anyway.
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.
Why not have a separate repository for people who want to replace core files so the ones who don't will never have to deal with this problem?
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.
Yes, that's the point of having an original OS repository, isn't it? What good is it you clobber it's consistency?
Now, regarding your statement about installing 2 programs alongside each other. Often programs don't even work if they are installed together
In that case it's poorly designed (except perhaps for the kernel and init) and you shouldn't run either copy.
and there is little need for normal users to have multiple versions (except in certain cases).
Those 'certain cases' happen. Especially in the RH scheme where if you want a stable kernel you never get any new app versions.
Besides, developers seldom use RPMs for simply testing their applications.
Obviously, or they would unstand the issue and not make it hard for other people to test them too - without breaking their working versions.
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.
OK, give them different names instead of conflicting ones then.
-- Les Mikesell lesmikesell@gmail.com