On 4/25/06, Dag Wieers <dag@xxxxxxxxxx> 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@xxxxxxxxx
