Slashdot Mirror
Ubuntu Developing Its Own Package Format, Installer
An anonymous reader writes "While complementing Debian APT/DPKG, Canonical is now developing their own package format. The new package format has promised highlights of having no dependencies between applications, each package would install to its own directory, root support wouldn't always be required, and overall a more self-contained and easier approach for developers than it stands now for Debian/Ubuntu packages. The primary users of the new packaging system would be those distributing applications built on the Ubuntu Touch/Phone SDK. The initial proof-of-concept package management system is written in Python and uses JSON representation."
This quote from the post by Canonical's Colin Watson bears repeating: "We'll continue to use dpkg and apt for building the Ubuntu operating system, syncing with Debian, and so on."
Good, another reason to avoid Ubuntu like the plague.
The world's burning. Moped Jesus spotted on I50. Details at 11.
If everything has no dependencies, then all of the dependencies must be included in the install. I wounder how many copies of each low level program would be on a given machine.
A better headline:
Ubuntu Phone apps will use a different package format than debian/dpkg/apt
I guess that's not really as exciting though
Would it allow users to install multiple versions of the same application from packages? One of my gripes with Linux is that it's not easy to test new or beta versions of software since there is no easy way to install from packages alongside the existing (stable) version. Yes, I know that I could build the app from source, but that can be quite a hassle sometimes.
http://en.wikipedia.org/wiki/Application_bundle
Once again, racing as fast as we can towards where the puck was 20 years ago.
I don't think we're going to see a completely separate install of Gnome for every single Gnome app on your system. I think this is intended for standalone apps like you see on phones and tablets.
I read the internet for the articles.
Which is actually even worse, because it has to exist alongside dpkg/apt. Still re-building the wheel and adding useless bloat, no matter how you look at it.
Designing the capability to bundle libraries with an application install is a good idea, the problem is.....
Ubuntu is building their own system for doing it, instead of using APT, which gets them 90% of the way there. Most likely, it will be poorly done, which is the common fate of those who are too lazy to understand existing systems.
"First they came for the slanderers and i said nothing."
Talk about simplicity. Here is an example 'Makefile' from Unix 6. Compare it to today's auto-tools:
/lib/liby.a *.o ../source /usr/bin/yacc /usr/bin/yacc
chdir lib
cc -c -O *.c
ar r
rm *.o
chdir
cc -s -O y?.c
cmp a.out
cp a.out
rm a.out *.o
"First they came for the slanderers and i said nothing."
actually, it's something that Windows gets dead-wrong, because executable installer apps (setup.exe and the like) are just plain fucking stupid.
they're an unfortunate necessity because windows doesn't have, and never has had a decent package management system. and is unlikely to ever get one because the windows software market is primarily commercial and proprietary.
when you have 10 (or 100 or 500) packages to upgrade on a single system (and then multiply that by 100 or 1000 systems), executing hundreds of installer packages one after another is the worst possible way to do it.
i've never understood why Windows (or Apple) users tolerate that shit. it's a tedious chore that's ripe for automation - exactly the kind of thing that computers are good at doing and users are bad at doing (due to boredom, fatigue, loss of attention, ignorance, or stupidity)
which is precisely why linux distros (and other *nixes) don't do it that way. they have packaging systems because systems are consistent, predictable, and easily automated.
windows users and windows developers often have just the wrong way of looking at things, the wrong mental model of how things work and how they should work.
I ran across a program for Windows recently called Ninite. It's a multi-app installer and updater. it sounds like a good idea and is. it's a big improvement over the usual click-and-execute for each individual program.
except the way it works is weird and clumsy:
you go to their website and select which apps you want to install (from a bunch of internet-available apps, including free software and proprietary freeware like adobe flash), and then it builds you an installer app that you download and run, and it installs and/or upgrades the apps you selected off their website.
WTF?
nice starting idea, but the implementation is idiotic. Why not just have one Ninite app that fetches a list of available apps and installer URLs and whatever custom installer scripts ninite needs for them) and allow the user to select which apps whenever they run it?
i.e. instead of a moronic implementation, actually make a smart and useful implementation that copies good ideas from linux distro installers like apt-get and yum, and re-purposes them for the Windows environment.
(oh, and adobe are sending cease-and-desist letters and threatening to sue if the ninite developer doesn't remove the ability to install & update downloadable adobe products like flash, so his good ideas and good intentions are fucked by the corporate vermin mindset that dominates the windows software market)
another thing windows devs don't get is shared libraries (DLLs in windows terminology). Why does every single app have to install their own copy of the MS C++ libraries? or .net? or nvidia physx? and numerous other common library packages? these things are supposed to be shared resources provided and kept up-to-date by the operating system, not bundled with every app that uses them.
*If* everyone picked exactly the same lib version, yes.
In practice, people aren't going to standardize on the same library version.
Bonus problem: Now each app provider is responsible for addressing a hypothetical libcrytpo vulnerability rather than the distro patching it in one place.
XML is like violence. If it doesn't solve the problem, use more.
Ubuntu is building their own system for doing it, instead of using APT, which gets them 90% of the way there. Most likely, it will be poorly done, which is the common fate of those who are too lazy to understand existing systems.
So you're saying Colin Watson is too lazy to understand existing systems? You've never actually looked at commits for APT have you.
Anyone on this site who is stumped by grep missing need leave. Now.
Call me old-fashioned, but I prefer a proper Makefile which only compiles the files required and which separates between the build and install phase.
bash$