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