Better Remote Upgrade Capabilities - Ideas?

Michael R. Head burner at
Fri Sep 14 20:27:31 UTC 2007

On Fri, 2007-09-14 at 12:33 -0600, Kevin Fries wrote:
> Chris,
> You are right, but the problem is actually at the core of the DEB/APT
> system.  It will not get fixed any time soon.  And for the record, RPM
> is not any better, it suffers from the same problem.
> The core of the issue stems from the fact that software exists in a
> n-dimension matrix.  This matrix is being modeled by a flat file
> structure.  This can not be done fully.  Now add the untold number of
> changes done by the developers to make our users desktops more useful.
> That model keeps changing, and the flat files are trying to keep up.
> This is not easy, and one little mistake can show up in a multitude of
> different ways.  Toss in the problems caused by third party repositories
> (and any solution that is incompatible with third party repositories is
> 100% broke in my opinion) and the problem becomes unmanageable.  The
> real answer would be a object oriented model, but that would break the
> DEB/APT system, and cause ciaos on an untold number of fronts.

I'm curious, do you have some specific, concrete examples of the sort of
chaos you're talking about?  

I get the notion you're talking about, but I would say that if any
problems actually occur, they are bugs that should be (and usually are)
fixed in the packages in question.

> The easiest way around the problem is a fresh install.  The problem is
> Debian (and thus Ubuntu) does not make this easy.  I feel that stealing
> the reinstall procedures from Fedora could resolve this problem without
> resorting to overhauling the APT system.  That is why I am seeking to
> contribute in this way.

I have seen some hiccups during upgrades, but nothing that would drive
me to consider a reinstall.

> Kevin Fries

Michael R. Head <burner at>

More information about the Ubuntu-devel-discuss mailing list