Ubuntu Developing Its Own Package Format, Installer 466
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."
apt (Score:4, Informative)
Sounds like a complement to dpkg, not a replacement
Goodbye Ubuntu (Score:4, Informative)
Re:but... WHY? (Score:5, Informative)
We need it because while current packaging systems are great for central control, they are bad for actually letting users contribute.
a) You cannot submit a bug to a developer, get a fixed beta release, and install that in the packaging system (unless you know how to handle spec files)
b) You cannot do parallel installations of newer (or older) versions for testing unless the package is built specifically for that
c) It is difficult to make distribution-independent packages, so users become dependent on the distribution for all software
d) Almost all packages require root, the packaging system cannot track software installed by users themselves
On the other hand, switching to a Mac-style packaging system has at least these problems:
1) Security updates to common code are unlikely to actually get applied to all packages
2) Some libraries will not be shared, costing extra memory and cache footprint
3) Centralized control over what software is installed suddenly becomes difficult
4) Without dependencies you need to define the minimal environment that software can depend on. LSB tried to do that and failed.
Re:Good (Score:5, Informative)
Go open a mac .app sometime. Libraries and resources galore can be found. The Systme libraries and frameworks can be over-ridden. like having ~/Library on a per-app basis.
Re:More Flexibility? (Score:5, Informative)
Microsoft solved this (partially) using a centralized registry...
Um, the MS registry is a huge pain in the butt for developers and M$ knows it, but they can't get rid of it becuase its too ingrained. Getting rid of the registry was a huge selling point for Windows 8, as it was for Vista... and so on. I dare you to ask me why... if you don't realize its a huge honey pot for virii and hackers you have no business even asking. Linux DOES INDEED have a system for library control, its called pkg_config and it works very well. Its not my problem if developers are too lazy to use it. 90% of linux apps I've ever envountered use it, so don't come whining to me there's no soluton this lib hell of which you speak. I do quite well with Linux, thank you.
Re:Good (Score:5, Informative)
"Dunno if there's a way to specify that inside Xcode or not, but for our app we use a build script that includes some code like the following. The code uses Apple's install_name_tool utility to modify the application so that instead of pointing to /usr/lib/libsndfile.so, it points to a libsndfile.so path that is in the application's package instead.
Note this is just a cut-down script excerpt to give you an idea; it will probably require some tweaking before it works for you (and of course you'll need to modify it to operate on other libraries besides libsndfile if that is what you want):"
http://stackoverflow.com/questions/7470637/dynamic-library-in-application-bundle-mac-os-x [stackoverflow.com]
Re:More Flexibility? (Score:5, Informative)
> That's because Linux suffers from a similar problem that Windows 95/98, and XP to a lesser extent did: DLL hell.
"DLL hell" has squat to do with it. The package manager is going to want to replace one version of an app with another. That is the only real problem here. If you ignore the package manager, you can install what you want.
Linux has had versioned shared libraries for ever.
The registry is just crap and you're a moron for even bringing it up in this context.
Re:More Flexibility? (Score:5, Informative)
There is no such word as virii either in English or Latin. The plural of virus is viruses.
http://en.wikipedia.org/wiki/Plural_of_virus#Treating_v.C4.ABrus_as_2nd_declension_masculine [wikipedia.org]
Re:More Flexibility? (Score:5, Informative)
> Does ldconfig allow for different versions of the same library to be requested by the application?
Yes.
> Does ldconfig warn you when a dependancy isn't met?
Better than that. You as a user can see what libraries are loaded from where and which ones are missing precisely.
The "superior alternative" is just a black box.
Re:More Flexibility? (Score:5, Informative)
Can you please point out which setting in the man page allows you to set this, oh great wizard of Linux? Because I think you're just being a contrarian right now, and haven't actually read the damn page.
You won't find that in the ldconfig man page because it's provided by the filesystem. This is a small snippet from the contents of my /usr/lib:
libboost_python-2.7-1_49.so
libboost_python-2.7-1_49.so.1.49.0
libboost_python-2.7-mt-1_49.so
libboost_python-2.7-mt-1_49.so.1.49.0
libboost_python-2.7-mt.so
libboost_python-2.7.so
libboost_python-3.2-1_49.so
libboost_python-3.2-1_49.so.1.49.0
libboost_python-3.2-mt-1_49.so
libboost_python-3.2-mt-1_49.so.1.49.0
Do you see what is happening there? Have you ever actually looked inside /lib or /usr/lib of a *nix system? Did you grasp what you saw? One application may need /usr/lib/libboost_python-2.7.so while another needs /usr/lib/libboost_python-3.2-1_49.so. Both get what they need.
In Linux the library's version is part of its filename. There is no "dll hell". DLL Hell in Windows was caused by a dll with a given filename being replaced by a different version with the *same filename* in the *same location*. I don't think you really understand the DLL Hell situation.
There's no man page for knowing what you're talking about.
Re:More Flexibility? (Score:5, Informative)
Query: ldd
Control: see the various environment variables that specify which lib dirs are used in what order for that environment you just created. (LD_LIBRARY_...)
Applications can specify the exact version number of a library (.so.1 vs .so.2).
Note, none of this is Linux specific. That family of operating systems is far from perfect in shared library handling, but I won't pretend that it doesn't inherit at least some tools that have at least some flexibility from older Unix tools.
Re:Bloat (Score:2, Informative)
Re:Bloat (Score:5, Informative)
How about comparing like-with-like instead of new software with software from 10 years ago:
Ubuntu 12.04 (released 2012): 384MB minimum
Windows 7 (released 2009): 1GB minimum for 32-bit, 2GB for 64-bit
Windows 8 (released 2012): 1GB minimum for 32-bit, 2GB for 64-bit
Plus the minimum requirement for XP was 64MB, with 128MB recommended (http://support.microsoft.com/kb/314865), not 32MB.
https://wiki.ubuntu.com/PrecisePangolin/ReleaseNotes/UbuntuDesktop#System_Requirements [ubuntu.com]
http://windows.microsoft.com/en-us/windows-8/system-requirements [microsoft.com]
http://windows.microsoft.com/en-us/windows7/products/system-requirements [microsoft.com]
Re:More Flexibility? (Score:5, Informative)
Who are you and what have you done with girlintraining?
The dynamic loader on Linux is very flexible. There are actually several different systems of varying granularity availble.
The coarsest is using LD_LIBRARY_PATH to allow one program to use a different .so.
The next is versioning with libblah.so.?, which allows different .sos to be made available depending on how the program was compiled. This requires a little bit of care on the part of the library author to actually bother to increment the version numbers.
The next, more complex is symbol versioning within a .so. This allows a single .so to have multiple different versions within it, so a single.so can actually serve multiple different versions. This is really good for system libraries and allows a great deal of backwards compatibility without bloating the number of libraries, and while allowing the maximum amount of code sharing. It requires the most discipline, so is generally only done by the dedicated libc and libstdc++ people. It's particularly important for system libraries, since it allows libraries which depend on "different" versions of glibc or libstdc++ to be linked together without trouble.
This is why a modern libstdc++.so.6 can happily serve g++ compiled binaries from just after the last ABI change to now without trouble.
Keeping hundreds of linux boxes up to date and patched is a fucking nightmare.
What? With the popular, sane distros, you can install some version with some reasonable support term (DeadRat, CentOS, Ubuntu LTS, Suse) and just tell it to auto-update the packages at 3 AM. You can even point it at a local package mirror if you want to save on external bandwidth.
In fact one can easily create a PXE installer which will install a customised package list and set up that configuration for you. Once you've done that, you buy a new machine, mess with the BIOS just enough to PXE boot it, choose the version you want and hit go. 1 hour later, you'll have a working, freshly installed system which will keep itself up to date with security patches until the distro drops off support.
If you want to rely on 3rd party programs which sit in /opt, it is very easy to download the program, untar it and chuck the files into a dkpg or RPM file, and then just add that package to the list. In fact people like LibreOffice only make APTs and RPMs available making it a minor faff to install on a less popular distro.
Again, once you do that, it will automatically roll out to all machines. Of course there's a bit more interaction, but then it is up to you whether you want to upgrade to a new major version of LibreOffice or whatever. And this way, the users won't get exposed to those program's nasty auto-updater scripts hassling them for new versions or whatever.
Honestly, if you're having trouble keeping Linux boxes up to date, then you are doing something wrong.