Better Remote Upgrade Capabilities - Ideas?
Michael R. Head
burner at suppressingfire.org
Fri Sep 14 21:27:31 BST 2007
On Fri, 2007-09-14 at 12:33 -0600, Kevin Fries wrote:
> 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 suppressingfire.org>
More information about the Ubuntu-devel-discuss