For the server administrator the whole problem looks IMHO totally different. I believe that the server administrator actually profits from an “everything is a package” approach with easy validation and easy management of all components on a single node. Of course *local* packaging cannot (and IMHO will never) solve the problems between servers. But a solid view on the state of a single node is a very valuable tool!

ATM I am working on a new data center management approach that follows an “everything is a file” idea and proposes to deliver all local files on a single node via packaging (RPM, DEB …). Including configuration, data (where locally stored), applications etc. The question how the packages are created is IMHO the key to achieving any degree of flexibility required, not loosening the concept of packaging all files on a server.

So far, this approach works very well (see http://schapiro.org/schlomo/papers/LinuxTag%202010%20-%20%20Advanced%20Software%20Management%20with%20RPM.pdf for an early version of the idea and ping me if you want to discuss it further). It obviously requires a central management solution that handles system interdependencies and obviously the application software should be more robust with regard to version mismatches.

In my opinion, the strength of “everything is a package” is the unbeatable strong control over a server and the validation of what is going on there. I would not want to miss that for my data center. And yes, the hurdle of packaging software with its dependency is a welcome stage in the quality assurance for the data center :-)

(3) Perhaps decoupling data will incentivise keeping data up to date particularly on systems that tend to be notoriously out of date in may respects like in the case of embedded devices, many of which are operated offline like cash registers, in-car entertainment, and even many consumer routers.

I think there’s something missed here on the “why” for local docs: it is not so much so you can have access to docs on unconnected machines (is there unconnected machines still there? and I don’t mean not connected to the Internet but disconnected al all -no LAN, no USB->PDA, no nothing), but to gain access to the *proper* documentation.

While you can go to the app site and look for more detailed information, forums, maillists, etc. where you can find information for *my* X.Y.Z version, which is the one I have installed? Upper maintainer web, docs, etc. focus on the new and flasy X+3 version and it doesn’t even support my Debian one.

Having docs aligned to what it’s installed has been a bless for my in quite many situations.

The problem with packages X, Y and Z are solvable. In the common case that Z is a shared library, the author should strive to provide ABI compatibility through various means, as described e.g. in Drepper’s DSO howto. Failing that, the packager should provide multiple parallel installable versions of Z. If all else fails, X and Y can always bundle a version of Z (like firefox for ubuntu nowadays does for some libraries).

And yes, indeed multiple branches per packages is not something that package managers support very well today. But I see no reason why such functionality couldn’t be added, if the community decides that such features are needed. While I’m personally involved in a few open source projects, I’m neither a debian nor ubuntu developer, so ultimately it’s not my decision to make, I can only offer my opinions and it’s up to the debian/ubuntu projects to decide upon the worthyness of those opinions. But Mr. Zimmermann’s blog post here suggests that even within the projects there are people who think the status quo is not the ultimate packaging policy for all eternity.

Mozilla did nothing to “force” ubuntu to ship major version changes as updates, the whole point of a distro is to smooth out things like that, if upstream drop support, then you guys pick it up and support it for the rest of the 1-2 years that user need it, not everybody wants the latest and greatest some of us want to install a system in 10.04 and know it will still be the same, supported, secure system until 13.4 (hint this is even more apparent when you look at users rather than outspoken geeks, e.g http://gs.statcounter.com/#browser_version-ww-monthly-200807-201007 shows a lot of people still on ie6 and ie7). I want to be able to install ubuntu on a pc, leave it running apt-cron and KNOW it will still work when I next go to my parents house in 6-7 months and that is very much what ubuntu wants to offer if your looking to expand (especially expand into corporate desktops)

Now there are a lot of loud geeks wanting in release updates (hell i run the latest kernel, latest firefox and latest xorg), but what these geeks need are PPAs not wholescale reform. What would be nice would be a change in the system so multiple lib versions can be installed and packages pick the right library (e.g no more /usr/lib/xulrunner, just /usr/lib/xulrunner-1.9 and all packages that need 1.9 know where to get it), that allows PPAs (or even 1st party PPAs) to offer multiple versions of an app side by side without crippling package management by packaging the dependencies with the package itself (this plays in very nicely with btrfs being used to save space)

I’m not too sure about data, maybe you have a point, but couldn’t -data packages be excluded from freezes, thus letting package maintainers issue updates much more easily and not requiring increases complication in the programs themselves (e.g why have update-pciids, when a package called pciids-data could exist and be updated regularly, hell for data packages it could be automated and would be just as reliable as update-pciides). There are cases where these solutions will not work, but i’d rather see apt-get-data or something similar at work so that the files are still checked/hashed and if needed can be easily rolled back and verified.

Last time i looked the way to download a python pacakge was apt-get install Python-$name, (there are ~1200 such pacakges), now i’m no expert on perl or ruby, but why can’t automated build systems or wrappers to/from apt be used to move all those dependencies through apt/dpkg rather than cpan/gem, if both were available as options a user would be able to either install the latest cpan modules (unsupported) through the wrapper or those supported with the ubuntu release through static packages (it’s my understanding that this is what happens with python and it seams to work well). With even 2nd/3rd parties offering deb installer (e.g when you compile your own kernel, there is a that option, when you install opera there is a repo for it), why are you so to go in the opposite direction and move away from apt/dpkg rather than integrate other tools with it.

As for embedded systems not being properly served by package management, well i think your probably right, but then again there is no need for “One linux”, besides i’s more to do with the packages themselves, you can always recompile with less support or build a huge repository of packages with different cflags and then match the cflags at update time. Sure if Ubuntu were to do this it would need new package management, but last I checked that wasn’t what Ubuntu was about to do (you also loose out on a lot of testing as fewer people will have any given package combo)

Sorry to disagree entirely but i think you asked some good questions and came to the wrong answers:
“How can packaging managers cope with embeded systems/virtual apps?” Why does this matter to ubuntu?
“How can packaging deal with constantly updating data?” By constantly updating.
“How can packaging deal with complex ecosystems out of it’s control?” Erm, if the systems are out of it’s control there is nothing it can do, if there is any way that package-management can help it’s by abstracting something bigger on top.
“How can ubuntu’s package manager cope with constantly updating apps?” They shouldn’t, there are already plenty of rolling release distros, multiple library versions would allow for nicer updating from PPAs though.
“What can we do about uncontrolled package management systems?” Take control of them through automated builds and wrappers.