Slashdot Mirror
The Future of Packaging Software in Linux
michuk writes "There are currently at least five popular ways of installing software in GNU/Linux. None of them are widely accepted throughout the popular distributions. This situation is not a problem for experienced users — they can make decisions for themselves. However, for a newcomer in the GNU/Linux world, installing new software is always pretty confusing. The article tries to sum up some of the recent efforts to fix this problem and examine the possible future of packaging software in GNU/Linux."
For those who don't TFA: There are currently at least 5 popular ways of doing it:
1) Installing directly from source code,
2) Ports-based installation (where the source packages are held in a repository and can be automatically downloaded, compiled and installed), like BSDs ports of Gentoo's portage,
3) Installing from distribution-specific packages like different versions of RPM, DEB, TGZ, and other packaging formats,
4) Installing from distribution-independent binaries (most proprietary software is delivered this way),
5) Using another distribution-independent system like autopackage, zero-install or klik -- none of them gained a significant market share so far.
PCLinuxOS uses a combination of Synaptic with RPMs from the PCLOS repository. Easiest package management I've ever used.
Most distributions let you convert&install/install other package formats, this article's problem is a non-issue in my opinion.
And no, I don't think drag and drop is easier. I just want to type the application name I was to install and that's it. Not having to worry about updates etc.
The OS X method:
Find website of program
Download program
Open disk image that contains program
Open applications folder
Drag and drop the application folder from the disk image
Create new icon in dock
Have to recheck the site periodically to check for a update for a specific program
Debian package system:
sudo apt-get install firefox thunderbird seamonkey
(you can choose multiple applications if you want even)
or graphically,
Open Adept
Type in program name
Click "request install" (you can choose multiple applications if you want even)
click install
Updates -- I wake up in the morning and see Adept telling me there are updates available for some of the software I use.
Change is certain; progress is not obligatory.
Using multiple package formats is great idea, IMO. I use alien on Ubuntu for those situations where the software I want is only avaliable in RPM, but as it says in the summary, new users can be a bit confused by this and building from sources is often too much. I would like to see GUI tools get the smarts to automatically figure out dependencies across all formats, allowing all distros to become package agnostic. Perhaps Linspire's CNR interace would be a good candidate for this.
Also, the option to resolve dependencies and install as a statically linked blob would be awesome for legacy stuff. I've lost count of the number of times I've wanted to install an app, only to find that it relies on some obscure version of xyz.so and won't work, so I find the source for the old version of xyz, only to find it depends on some older version of abc.so. If I could get this xyz.so, etc without conflicting with that xyz.so, create a static binary and put it somewhere under /opt, I'd be happy. I know it's not elegant, and that it uses more storage, but as a work around for difficult to support stuff, it ain't so bad when storage is cheap. Some apps I always install as blobs anyway, such as blender.
BTW, from TFA: Network Access Message: The page cannot be displayed :-(
Slashdotted
I don't therefore I'm not.
Apt rules, shame about dpkg. Even bigger shame that apt is built on dpkg, eh?
What pisses me off is the 32 step process to making a deb (that's what dpkg calls a package btw.. just incase you're playing acronym bingo out there). So if you want to install something you built from source, and be able to remove it later, you need some freakin' magician to have made it into a source package.. cause there's no way in hell you're doing it yourself.
What really depresses me is that debs, dpkg and apt, that's about the best anyone has done. Unless, of course, you actually like building everything from source.
How we know is more important than what we know.
up2date (front end for RPM) includes the option ("5. enableRollbacks yes/no"). RPM supports rollbacks, config files would be saved as [filename].rpmsave or [filename].rpmnew depending on exactly what you are doing.
Checkinstall http://www.debian-administration.org/articles/147
It's not the answer to all issues regarding installing from source
Any suggestions on what would make them even better?
up2date -i [package name]
"This package will require the installation of these additional packages, accept?" Yes/No
#2. The same for upgrading the software.up2date -u [package name]
"This package will require the installation of these additional packages, accept?" Yes/No
#3. The same for removing the software.rpm -e [package name]
#4. The same for handling dependencies. Including the order in which dependencies must be installed.Already done, see above. up2date will find dependancies, dependancies of dependancies, etc. until it is done, then present you the list and confirm to install all the packages, you hit "Y" and you're done.
If you just want to check what would be a dependancy you can:
up2date --solvedeps=[package name]
which accepts a comma deliminated list of packages as well as a single package name
#5. The same for validating the installed software against the original software (checksums or whatever).To verify packages installed (or package files not yet installed) you use the verify option:
rpm --verify
Which can check the GPG sig of the package file, the MD5 sigs of the files, etc. allowing you to detect any tampering or changes.
#6. The same for re-installing the software over the existing installation when you accidentally delete or over-write something.up2date --force [package name]
rpm --force [package name]
#7. The ability to point the updater at your own repository or multiple repositories./etc/sysconfig/rhn/up2date
serverURL[comment]=Remote server URL serverURL=https://xmlrpc.rhn.redhat.com/XMLRPC serverURL[comment]=Remote server URL serverURL=https://www.centos.org/XMLRPC #8. The ability to recompile (automatically) any software that you install for your specific hardware.rpmbuild -ba
But in general major vendors provide optimized packages for various architectures that rely on heavy math/etc (kernel and OpenSSL being two of the important ones)
You padded the Mac list with the following:
Your Debian list conveniently leaves out having to click the KDE start menu, fire up a Terminal window, type in the root password, waiting while the package manager goes through dependencies, etc. What a phony comparison of steps. I could just have easily reduced OS X's step to one line of "Drag app icon to Applications shortcut" in the same the way you reduced Debian's steps.
"Sufferin' succotash."
You're not misinformed, although the author may still have a point of including it on the list of base distributions. There's a slew of Linux distributions based on Ubuntu. Still, you're right. The grandpappy of them all is Debian.
Here's a fairly comprehensive list of these distributions.
At least in the RPM-speaking world, we already have this functionality in the SRPM, though not in a formalized sense. Often, compile-time options require only very small changes to the spec, or can be given on the command line. For example, the bytecode compiler option for most freetype RPM packages falls into this category.
I believe that the set of people who want to go gung-ho securing their boxes, who know what they're doing, AND who can't be bothered to recompile packages from SRPM form is very small.
With all respect, making statements like the above only indicates that you don't fully understand what Gentoo versioning is about.
"200x.x" just applies to the downloadable fixed distribution of Gentoo and is really only relevant if you have brand spanking new hardware that you need to work at the point of installation - then, possibly, you might wait for 2007.0 to come out because that would boot from a later Linux kernel that supported that hardware.
Perhaps another reason might be that in building your Gentoo apps from source, 2007.0 will probably have a pretty recent GCC compiler version on it - whereas with 2006.1 you'd need to update the GCC and the toolchain first to get to what 2007.0 offers.
But otherwise, once you get Gentoo installed and start updating your system with Portage, you'll use one single portage tree no matter what version of Gentoo you originally installed with so at that point, the version you originally installed with becomes pretty much irrelevant.
Gentoo Linux - another day, another USE flag.
Well, the system may be perfect, but the packagers certainly are not. It's next to impossible to get a new package into their repositories (I've been asking for over 2 years now !), which is I why I have to rely on the good people at getdeb.net (Ubuntu), and debian-multimedia.org (debian).
MSIs are one of the best ideas for Windows in a while
note that MSIs are nothing new, office was using that system (with a stub exe to make sure the microsoft installer was installed first) from office 2000 onwards and i think win2k shipped with it as standard.
Some people seem to think that the fact that Debian does things differently from Mandriva that does it different than Fedora is what makes the distribution "special". Be that as it may, I think it's only hurting Linux users as a whole.
It is certainly a problem, trouble is the moment you get standards bodies involved progress slows to a glacial pace, distros understandablly want to be able to improve the way thier libraries are packaged to meet thier users needs.
In many ways windows represents the opposite extreme, they are only just now (with the 64 bit versions) dropping support for win16 apps, windows contains a huge ammount of cruft for backwards compatibility.
another problem is that library authors act in ways that make it very hard to build binaries on a newer system that will run correctly on an older system.
a final problem is that menu systems vary so even once you get a binary on the system in a way it will run (though i belive freedesktop.org is trying to work on getting this standardised)
tools like autopackage try to work arround theese problems but doing so is easier said than done.
note: i'm known as plugwash most places but i screwd up registering that here somehow in the past and now can't register
That's exactly how Microsoft tried to solve it and why their distributed software is huge. It also has led to problems of competing dlls which are often incompatible. If you think you have dependency problems now, just wait until you implement your idea! Imagine installing 16 applications each having a dependency on 16 different versions of the same lib.
B.
This is a sig. This is only a sig. Had this been an actual sig you would have been informed where to tune for more sigs.
His point was not that everyone should use Gentoo, but rather that Portage was designed as a repository that handled binaries and source easily side-by-side.
And I agree, the solution really is to have one major package repository. How you package it isn't horribly important.
The problem is that each major distro is built using different versions of libraries with completely different toolchains, and they use different patches, etc.
That is why most repository systems won't work.
However, here is why Portage would work for all distros. Keywords.
By using "SUSE" as a keyword, it could pull the binary compiled using the SUSE toolchain if that is what you needed.
The world won't start using one distro. And SUSE can have their binary packaged in their format, and Ubuntu can have it packaged in their format, but we really, really do need one repository.
http://blindscribblings.com - Tasty pop-culture in conceptual fashion.
"What is Internet Explorer 7? Are you saying we can't access the normal internet?" - I love tech support. Really.
If you use a package manager, that is how installing programs on Linux is.
"What is Internet Explorer 7? Are you saying we can't access the normal internet?" - I love tech support. Really.
The difference between OS X and Linux is that the base OS X installation is huge, and already includes many shared libraries. For example, you can assume that libcurl will be always available on OS X - not so on Linux. You seem to be saying that OS X apps don't depend on shared libraries, which is just not true.
Wine is in the repositories of pretty much every distribution that has repositories (and actually, Oracle is in Ubuntu's repository). As for the specific Windows applications, the discussion is package management, not what programs are available for Linux. If you are very attached to Windows apps that don't work with Wine, then unfortunetly Linux is not for you. We should continue to complain to software developers to make Linux ports and make our own equivalant programs, but that's a seperate issue from the best ways for users to install the software that is for Linux.
"What is Internet Explorer 7? Are you saying we can't access the normal internet?" - I love tech support. Really.
I personally like the package management system. I like having one place to look for software for my system, software that I know has been tested with the programs I likely have on my system, software that I know will update with the rest of my system, software I know isn't spyware. It sounds like it wouldn't work too well, but it really works rather well since there are so many programs in the repositories. Even for the programs that don't want/can't be in the repositories, there's ways for people to install those easily as well. There's java programs that install easily regardless of your Linux, there's autopackage, and some developers just put the program and all the files in a zip file that you can extract and then run where ever you want. There are solutions, they probably need better development, but they're not in terrible shape and that's not the most pressing issue for Linux. Much more important is getting the software people really want on Linux (or at least working really well and easy with wine) and making really good oss equivalents to proprietary software (we need something better than gimp to compare to photoshop) and we also need more device drivers, especially wireless. Those are much more important than package management.
"What is Internet Explorer 7? Are you saying we can't access the normal internet?" - I love tech support. Really.