[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: Using apt dist-upgrade



On Fri, 2005-04-15 at 19:52 +0530, Rahul Sundaram wrote:
> Ralf Corsepius wrote:
> 
> >On Fri, 2005-04-15 at 19:06 +0530, Rahul Sundaram wrote:
> >  
> >
> >>Mark Haney wrote:

> >He just has released a new release, a couple of weeks ago.
> >
> 
> I had that impression through previous discussions related to it in 
> Fedora devel list and the fact the issues like multilib is/was there for 
> a long time
Yes, apt still is not able to handle RH multilibs.

> >> So Fedora development is going to concentrate on 
> >>supporting a live upgrade, then yum is likely to be a better choice than 
> >>apt.
> >>    
> >>
> >True, except that yum has not yet reached a shape to be usable for "live updates".

> 
> I am not sure apt does it in Fedora either
Well, 95% of the issues wrt. upgrading RHL/FC are packaging bugs. These
affect all upgrading tools, such as up2date, apt, yum, smart and
anaconda.

So if you know how to work around these packaging bugs, in theory there
should not be much difference between these tools and you should be able
to upgrade using any of these tools.

In practice. this is where things are going to diverge, because you're
going to trip the side-effects of implementation and the different
problem solving strategy these tools implement.

So far, I have been able to successfully upgrade my systems from RH-8.0
through FC3. All experiments to do the same with yum, so far have failed
or had proven to perform unacceptable.
Don't get me wrong, IMO, yum is gradually improving and has evolved to
acceptable shape as far as "keeping systems up2date" is concerned, but
it is still at least one magnitude behind apt elsewhere.

Smart is a promising tools, which tries to incorporate features from
yum, apt and others. In comparison to apt and yum the main difference
between smart and apt/yum is them using different dependency resolution
strategies. They are different and matter to personal preference, but
that's basically all. The resent libtool vs. gcc incident made this
clear.

I prefer a tool that refuses to remove packages in case of conflicts
(yum/apt), others wondered why "this'n'that" packages suddenly vanished.

Ralf



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]