[SPAM] Re: [CentOS] dag repo and perl dependencies naming

Tue Apr 25 22:40:51 UTC 2006
Les Mikesell <lesmikesell at gmail.com>

On 4/25/06, Dag Wieers <dag at 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 at gmail.com