increase apt flexibility (for third party apps)

[MadMan2k]

Mike Hearn wrote:

>I question any user interface that has deeply nested trees (really any
>trees at all are questionable). Usability testing has shown that many
>people have difficulty with trees, which is why GNOME upstream has been
>gradually eliminating them over time. See spatial Nautilus, the new GTK+
>file picker and so on.
>
>Search/navigational interfaces seem to be easier for people,
>which implies that finding and installing software should have a web-like
>user interface. Why not use the web itself then? This is the user
>interface we settled on with autopackage and it seems to work nicely
>(though others - like an apt-get style UI - are certainly possible!)
>
>  
>
I was rather talking about the data saving structure - there are many 
possibilities to actually display a tree.
A forum like www.ubuntuforums.org is called a board, which means that it 
displays never more than one node at once
but its a tree nevertheless.

Also you could look at the web as a huge tree with links being only 
permutations of the branches.

>It's not exactly correct that autopackage "requires" ABI compatibility and
>Ubuntu native packaging does not. Every operating system, regardless of
>what package management they use, requires some level of backwards
>compatibility, usually the more the better. The less you have, the less
>efficient your system is and the more prone to mistakes and unreliability
>it is.
>
>The autopackage project provides programs like relaytool and apbuild to
>work around less-than-stellar binary compatibility on Linux, but this is
>not significantly more complex than the Ubuntu approach of centrally
>compiling everything on build servers.
>
>Consider this. It takes time to ensure binary compatibility, whether it's
>done using apbuild/relaytool style addons or guaranteeing it upstream.
>
>However, it also takes time to use the Debian approach. Look at the
>massive timesink that upgrading GCC can be - it refuses to compile more
>and more code with every release. This code must either be modified to
>compile with the new compiler, or left behind. Where source code breaks,
>sometimes binaries continue to work correctly. 
>  
>
but the trade off is a more bloated system, since you will need to keep
GCC3 and GCC4 libraries due to ABI incompability.

Updates could be less bandwidth intesive if binary patches would be used 
instead of
being forced to download the full package again and again.

Bun generally you are right, this is not a black or white issue, 
therefore ABI
compatibility should be considered as far as possible, but this should 
not slow
down the development process - where breaking the ABI is necessary it 
should be done,
since this is a advantage of GPL software and it should be kept.

M2k