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."

Comments

The solution!

[Stormie]

Why do I have a sneaking suspicion that the solution will be to create a sixth way of installing software, which will also not be widely accepted throughout the popular distributions?

Re:The solution!

[tigerflag]

PCLinuxOS uses a combination of Synaptic with RPMs from the PCLOS repository. Easiest package management I've ever used.

Re:The solution!

[SnowZero]

Don't worry, a seventh way will come along to wrap those first six which don't solve the problem, and it will be the ultimate meta-universal generic packaging system.

Re:The solution!

[Max Littlemore]

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 :-(

Re:The solution!

[M. Baranczak]

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.

The package formats are easy. The real bastard is that each distro has subtle differences in how the packages and the dependencies are organized. The only way that I can see to fix that is to design a universal package tree, and convince all the major distros to conform to it. Which is not impossible, but it aint easy, either. And it might cause other problems.

Re:The solution!

[Anonymous Coward]

A great idea??? Are you serious?

Choice is good - until the point where it becomes totally overwhelming. On linux there are dozens of distros to chose from (different versions of the said distros too - running on different versions of the kernel), different window managers to chose from, different installers (apt get or whatever, applies to both the command line and the graphical installers), different package formats, different shells, too many different text editors (vi/emacs/...) and such.

Most users appreciate SOME choice. Like when you go to the dealership, you pick the car model, the engine, color and such. The linux way, you'd be forced to hand pick things like the actual metal alloy used for the pistons' segments and such intricate things most people couldn't care less about. Yes, you could have a totally custom car, but it would take 6 months to pick all the parts by hand, and comparing the cars to another would be so complicated and overwhelming...

Too many confusing choices to make, often over stuff one doesn't really understand. And when searching for information about them (to make the choice), often all one finds is heated debates (like kde/gnome or emacs/vi) without much real information.

When I use my PC at home, at work, on the road, at friends or relatives' places, it's always the same interface (plain old WinXP), same way to do things, stuff located in the same places, most apps are the same, etc. Predictable, consistent and simple. Most people truly appreciate that.

If we were all running linux, I'd be using say, KDE or gnome, work might be using fluxbox, a friend would use something like xfce... All on different distros that work differently and have different apps installed by default (likely not the ones you're used to). I'd be lost.

Re:The solution!

[kripkenstein]

The package formats are easy. The real bastard is that each distro has subtle differences in how the packages and the dependencies are organized. The only way that I can see to fix that is to design a universal package tree, and convince all the major distros to conform to it. Which is not impossible, but it aint easy, either. And it might cause other problems.

Regarding the issue of dependencies, they might just be ignored completely for desktop applications (the focus of TFA). For server apps, you want to rely on shared libraries in your distro's repositories, but for the odd desktop app, the simplest solution may be to just include all dependencies inside it. Yes, this creates some security issues (patching the included dependences), so it isn't a perfect solution. Also it can waste some RAM. Still, if a new user has to have some brand-new desktop app, this might be the easy way to do that.

Other related issues of installing in various distros with various directory setups can be solved (partially, at least) with app virtualization. I believe Klik is doing something along those lines.

Re:The solution!

[nmb3000]

The real bastard is that each distro has subtle differences in how the packages and the dependencies are organized. The only way that I can see to fix that is to design a universal package tree, and convince all the major distros to conform to it. Which is not impossible, but it aint easy, either. And it might cause other problems.

Which is why, as it currently stands, this year will not be Year Of The Linux Desktop. Consumers won't just accept that they can't install software X because it's an RPM and alien doesn't work (this is of course after looking online for half an hour to figure out that alien is the tool to use). Manually compiling from source is simply not an option for standard users. Sure it's a dandy idea, and if you get a "fullproof" GUI that handles the compilation and installation then maybe, but I can't count the number of times make/make install has failed for some obscure reason. The first time grandma needs to go download dependencies means Linux has failed on the consumer desktop.

This is one place that Microsoft and Apple have it right. By having a standardized method of installing and storing program information they make getting new software many times easier than on Linux (excluding the "normal" packages. I'm thinking more along the lines of tools and apps you download from the web). This is also one reason people are willing to pay for an operating system that has a standardized and dependable way of doing things.

Microsoft even released the WiX toolkit that allows anyone to create MSI installer packages. MSIs are one of the best ideas for Windows in a while: No more dealing with poorly-written homebrew installers or 10-year old, 16-bit InstallShield programs. Instead you have a fully scriptable installer that's transaction-based and has near 100% support coverage.

I like apt, but downloading a gzipped file of source or a deb that complains about dependencies still can't compare to an MSI package. Even if a solution was developed that worked as well as or better than MSI, as you say, it would take significant effort (and maybe not even then) to get it supported by all the major distributions. 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.

Re:The solution!

[muuh-gnu]

> Like when you go to the dealership, you pick the car model, the engine, color and such.

When youre a newbie, and searchig for a Linus distro to check out, it isnt any different. You then either just pick the one you saw somwhere work nicely, or go with one of the widely recommended biggies: Fedora, Ubuntu, Suse. They mostly provide sane and easy to learn defaults, and do not confront the newbie with stuff like vi/emacs, kernels, shells and window managers unless he _deliberately_ looks after them.

Saying that the sole existance of some obscure sourcebased distro or window manager he wouldnt even be able to install is making the first choice to a newbie _SO_ difficult, that he shuns Linux alltogether, is like saying people would stop driving and buying automobiles, because of the existance of limousines, sport cars, monster trucks, forklifts, lawn tractors, and so on. You do not get confronted with those in a car dealership. You also dont get confronted with advanced level distros and apps wheny youre a newbie.

Re:The solution!

[petermgreen]

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.

Re:The solution!

[juergen]

Now that's one of my pet peeves.

Why the fsck do some users insist on installing software outside their own distributions?

1. They have a weird distro. Switch. All modern distros include virtually everything a common uswer needs.

2. Common users should stay away from bleeding edge versions. Treat them as non existant, like you don't see half finished products in the MS world. (Well, ...)

3. They have more than basic or intermediary needs. They are not common users and should be able to cope with the current situation.

4. They just are not educated they can get all they want from their own distro, and stupidly follow instructions on a product's webpage more directed at packagers. No wonder they are frustrated.

Another *unified* approach will not work in a world where distros mainly distinguish themself by doing (package) management different. It'll create more fragmentation, like another LSB failure.

Few users expect to be able to install Windows software on Macs either. And nowadays it is even the same hardware. The key to winning this is education, and letting distro's compete on their core bussiness, not forcing a one for all solution on everyone.

-Jürgen

Re:The solution!

[trianglman]

and do not confront the newbie with stuff like vi/emacs, kernels, shells and window managers unless he _deliberately_ looks after them.

Unless, of course, the newbie does want to install a software package that doesn't come pre-installed with the distro chosen. Once that happens it is a crap shoot at best whether it is even possible to install the new software, which is what this article is all about. What needs to happen is for the core Linux user base to get over their egos (I know I am going to get an "Are you new here?" for that) and realize that ease of use for the general public is more important than doing things they way they have always been done. Windows has gone far past the opposite extreme and made everything so easy to do that one can't do anything, but there is a middle ground. Doing things in an inter-operable manner wouldn't preclude custom, build it yourself, distros, it would simply make it easier for a newcomer to start and get the software they want to use.

Re:The solution!

[trianglman]

packaging is the most major part of a distribution's job.

This is one of the places Linux gets it wrong. My operating system should not be responsible for all the software I might at some point want to install. Windows messes this up too at times (IE), but MS is much less of an offender than Linux is. It should be responsible for making it easy to install new software, among many other things, but it should not be responsible for every software program out on the web.

An operating system should be responsible for the kernel, file system, and the nuts and bolts of keeping the system running in general. The program creators should be responsible for packaging so that it can be installed (with the help of the operating system) and should also be responsible for dependencies. It should not be my job to spend three hours searching the web for some obscure package that the program creators just couldn't do without. If they see it as necessary, and they know its not readily available, they should package it with their own program (GPL and BSD licenses both support this and is one of the strengths of these licenses).

Re:The solution!

[penix1]

the simplest solution may be to just include all dependencies inside it.

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.

Re:The solution!

[Enderandrew]

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.

Re:The solution!

[Serious Callers Only]

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.

The idea of the post you're replying to was to package dependencies inside the application. That way, you can indeed install 16 applications each having a dependency on 16 different versions of the same library, with no problems whatsoever.

OS X does it this way just now, and it works very well; apps are sometimes a few MB bigger (not a huge amount for most apps), but it's a huge saving in convenience for the user, who shouldn't even have to know what a dll/shared library is, let alone worry about it. As the grandparent pointed out, packaging applications should be a job for developers, not the OS.

Re:The solution!

[trianglman]

Why do Linux fundamentalists believe that all users are idiots and they should go somewhere else? Until the majority of Linux users and developers get past this mentality we will never see Linux accepted into the main stream desktop market. Yes, most general users can find all the software they need in a single distro, but most users don't know Ubuntu from Fedora from SUSE. If they pick a distro that doesn't include a software package that they want it shouldn't require uninstalling the OS and installing a new one. Distros shouldn't have to include every single piece of software that a user might want also. If they stopped doing this distros wouldn't require 5+ CDs or a DVD or two. Now, don't get me wrong, I appreciate having most of the programs I will need available on a set of five CDs, but this shouldn't be a requirement of distros. MS took that mentality with lots of things (specifically IE and the media player) and got slammed with anti-trust lawsuits. The non-system required software should be independent of the operating system, making the other software easily available is a feature of the different distros, but you shouldn't have to pick a distro based on the software that will come prepackaged.

Re:The solution!

[mrsbrisby]

Which is why, as it currently stands, this year will not be Year Of The Linux Desktop. Consumers won't just accept that they can't install software X because it's an RPM and alien doesn't work

Now my daughter just received a "game" on Windows- brand new (2007) game that insisted on running in some "compatability" mode in Windows, and in a resolution that her LCD display couldn't cope with. The fact is that Windows users have run into this problem attempting to install software that isn't for their particular operating system, and failed on the Internet for a few hours. They just assume that Linux users have run into the same problem.

They don't. Linux users install software out of their software catalog. Occasionally the brave ones go to the author's website, and download the software from there.

This is also one reason people are willing to pay for an operating system that has a standardized and dependable way of doing things.

Bzzt. Wrong. Nobody is willing to pay for Windows, that's why Microsoft doesn't let OEM's give you a choice. Duh, I'll use the Windows I already bought. And don't spread that Lie about how I don't have a License to.

Microsoft even released the WiX toolkit that allows anyone to create MSI installer packages.

But not the MSI format specification. That would allow me to cross-compiler into an installable package. As it stands, my users who run Windows have to deal with no installer.

MSIs are one of the best ideas for Windows in a while ... No more dealing with poorly-written homebrew installers or 10-year old, 16-bit InstallShield programs.

You're wrong, and you want proof? Look how many programs- nay, look how many programs come from Microsoft that are still distributed as exe files. That shiny new Zune's software comes in exe-form.

Once that 16-bit installshield program was written, it's forever supported. You can't put the setup.exe genie back in the bottle, and you have to live with that. With Free Software, we can take our software library with us, which is why Free Software always gets better, and non-Free software atrophies.

Instead you have a fully scriptable installer that's transaction-based and has near 100% support coverage.

You are wrong on all counts. Pull the power plug while installing and you'll see just how transactional it is. I don't even think you know what coverage means: Microsoft Support will tell you to reinstall your operating system if a broken/corrupt/poorly-written MSI breaks your system. Even if they make it.

I like apt, but downloading a gzipped file of source or a deb that complains about dependencies still can't compare to an MSI package.

No of course not, but that's why you used a straw man. MSI is an executable, and just made Microsoft's security problem worse: it introduced yet another executable file format. Nobody downloads "gzipped file of source or a deb that complains about dependencies" ever. They say "apt-get install xyz" and it goes and figures out the dependancies itself.

It doesn't have to- Linux users could waste disk space by including the dependencies with every program- and some Linux distributions even do this(!), but it makes upgrades very difficult. For example, when libz had a vulnerability discovered, only one copy needed to be upgraded on most Linux systems. On Windows, almost every program that dealt with gzip or deflate-compressed data (like png or zipfiles) needed to be upgraded. Worse still, that library or program can be anywhere on your hard drive, and you might never know it.

Re:The solution!

[ElleyKitten]

Why do Linux fundamentalists believe that all users are idiots and they should go somewhere else? Until the majority of Linux users and developers get past this mentality we will never see Linux accepted into the main stream desktop market. Yes, most general users can find all the software they need in a single distro, but most users don't know Ubuntu from Fedora from SUSE. If they pick a distro that doesn't include a software package that they want it shouldn't require uninstalling the OS and installing a new one.

If a user picks Fedora or Ubuntu or SuSe, then they should be able to find just about anything they need in their distro's package manager. They all include alternative web browsers, chat clients, games, KDE/GNOME/XFCE, programming tools, image editing software (as best as it gets in Linux), wine, and even different file managers and shells and stuff that average users would never care about switching from the default. If a newbie picks Slackware or DSL or FreeBSD and figure out what to do or how to install programs, then yes, they should switch to a more mainstream and newbie-friendly distro. But there's not that much differences in what's in the repositories of the main distros, so they shouldn't need to switch from Fedora to Ubuntu because of what packages are available.

Distros shouldn't have to include every single piece of software that a user might want also. If they stopped doing this distros wouldn't require 5+ CDs or a DVD or two. Now, don't get me wrong, I appreciate having most of the programs I will need available on a set of five CDs, but this shouldn't be a requirement of distros.

It's not a requirement of distros. Ubuntu and other distros are available on single CDs, with all of the rest of their programs available in the repositories, so you only have to download multiple CD or DVDs if you're installing to a computer without internet or if you just like having all that stuff offline.

Re:The solution!

[ElleyKitten]

Agreed. Multiple package formats are a non-starter, and shouldn't even be a consideration. The LSB has standardized on a subset of RPM, and that should be the universal package format. The Debian-based distros are harming the package standardization processes, and should learn to play with the other children. Debian's strength is not in the .deb package format, but in the package management tools. Those same tools will still be available upon switching the the LSB RPM format, so I don't see Debian's hangup about cooperating with the LSB.

Why should the Debian-based distros scrap their package format? There's just as many if not more users of Debian-based distros than there are Red Hat based distros, so why is it that the Debian distros have to do all the work to change? Couldn't you just as easily accuse the Red Hat distros of not playing with the other children because they don't want to switch to .deb?

Software installation needs to be simple as: click on package, enter password to authorize installation, use newly installed software.

If you use a package manager, that is how installing programs on Linux is.

Re:The solution!

[Jesus_666]

It should not be my job to spend three hours searching the web for some obscure package that the program creators just couldn't do without.

Hence package management. You either distribute everything statically-linked (which means that if a critical bug is found in a library all programs using that library need to be updated) or you make the programs and the libraries they use separate packages, which allows fixes to be distributed more easily. With a good package repository you should not need to hunt down anything, ever.

Linking everything statically would mean no problems - provided that all programs come with an auto-update routine, the auto-update routine is implemented in a way that makes sense to be deployed in a sensitive network, all authors keep up to date regarding the libraries they use, fixed builds are made available as soon as possible.
As long as that scenario is not reality package managers are useful.

Re:The solution!

[ElleyKitten]

Nobody is willing to pay for Windows

I actually know a guy who purchased a brand-new copy of Vista for the computer he just built. Of course, he also unplugged all his fans when he was afraid that his power supply wasn't strong enough, so he's not exactly bright.

Re:The solution!

[_xeno_]

But not the MSI format specification. That would allow me to cross-compiler into an installable package. As it stands, my users who run Windows have to deal with no installer.

WiX is fully open source, so if you wanted, you should be able to figure out how to create MSIs from that. In any case, you could try running it under Mono, maybe it'll work under Linux...

MSIs are one of the best ideas for Windows in a while ... No more dealing with poorly-written homebrew installers or 10-year old, 16-bit InstallShield programs.

You're wrong, and you want proof? Look how many programs- nay, look how many programs come from Microsoft that are still distributed as exe files. That shiny new Zune's software comes in exe-form.

Most of those EXEs are actually MSIs wrapped with a stub installer that can install the Windows Installer if it's missing.

No of course not, but that's why you used a straw man. MSI is an executable, and just made Microsoft's security problem worse: it introduced yet another executable file format.

Well..... yes. It is. Sort of. It allows arbitrary binary code to be run - but then again, it's an installer. It could run arbitrary code anyway. Complaining that MSI is "another executable format" would be like complaining that RPM is "another executable format" - it's equally true. (Although I think RPM generally runs shell scripts, not direct binary code. Although I could be wrong.)

Nobody downloads "gzipped file of source or a deb that complains about dependencies" ever. They say "apt-get install xyz" and it goes and figures out the dependancies itself.

Right, nobody does that because it's practically impossible to get it working. Instead they discover that it's not in the apt repository and give up. That's the problem with the Linux packaging system - if it's not there already, it's basically impossible to install unless you're a Linux expert. Now you might say that "any software you'd ever need" is going to be available, but you're guaranteed to be wrong at some point. Some new game, some new app, something will become available that someone will want to install - and won't be able to, because it's not in the distribution repository.

Worse, from the developer point of view, they might create some great new software that they want to release in an easy to install form - and, really, can't. Maybe they'll generate an RPM or a DEB for their own installed Linux distro, but beyond that, it's just too much effort to try and make an installer for everyone.

Oh, and MSI is horrendously overcomplicated compared to RPM and DEB, in case you wanted to know. Nothing like having to generate a GUID for every single file you might want to install. (Although to be fair, that's likely because most Windows programs don't contain all too many files.)

Re:The solution!

[M. Baranczak]

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.

Re:The solution!

[ElleyKitten]

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.

Re:The solution!

[MBGMorden]

Last time I tried Ubuntu apt-get package_i_want failed to locate the program more than half the time. I use Gentoo and while portage has the largest selection of "packages" available that I've seen, even it does not contain everything.

Relying on distros for your software has lead to the sad state we're in now. I don't rely on Microsoft to hand stamp and prepare every piece of software I used on Windows, and I certainly shouldn't have to do the same on my Linux machine. Until we get a method by which I download a file, click on it, and install a program (regardless of which distro I'm running or which version of GTK I'm running), Linux will lag behind. SEVERELY.

Re:The solution!

[ElleyKitten]

Last time I tried Ubuntu apt-get package_i_want failed to locate the program more than half the time.

When you use the command line you have to make sure you spell the package name exactly right, for example "sudo apt-get install flash" won't work, but "sudo apt-get install flash-nonfree" does. Synaptic has a really good search feature that I use when i don't know the exact name. If Ubuntu really doesn't have half the programs you want, then what programs do you use and how do you normally get them?

Relying on distros for your software has lead to the sad state we're in now. I don't rely on Microsoft to hand stamp and prepare every piece of software I used on Windows, and I certainly shouldn't have to do the same on my Linux machine. Until we get a method by which I download a file, click on it, and install a program (regardless of which distro I'm running or which version of GTK I'm running), Linux will lag behind. SEVERELY.

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.

Re:The solution!

[AeroIllini]

Ok, so the binary package capability of Gentoo may not be completely unused, but it is used sparsely, if that. A very few select programs have binary equivalents (OpenOffice, Firefox, and Azureus come to mind), but what I think the GP is looking for is a way to specify "all binary, all the time" as a build option. I'm certainly looking for that. Combine that option with the newly-introduced graphical installer, and voila! Gentoo can be used as a Grandma System, too.

What the Gentoo devs need to do is to add arches like x86-bin, amd64-bin, etc. to the Portage tree, and these arches would not compile anything--just install binary packages. Every time this is brought up, many Gentoo devs jump to the defense of building from scratch, saying "if you don't want to build from scratch, what the hell are you doing using Gentoo?" And I usually respond with something along the lines of "but isn't Gentoo all about choice? And shouldn't I have the choice to install binary packages?"

The binary packages would be standardized on a certain set of USE variables, and only compiled for each arch/CHOST combination (to reduce storage costs at the repositories). If someone needs a specific set of USE variables for a particular package, they can build from source by specifying a non-binary arch in their /etc/portage/package.keywords.

The beauty of Gentoo is scalability; the system can be tailored to be anything you want it to be. This will add one more option: Gentoo can also be a binary distro, suitable for non-hardcore users. If Debian can do it, why can't Gentoo?

Re:The solution!

[mstone]

---- Why the fsck do some users insist on installing software outside their own distributions?

Uh.. because they want to?

Because they think the software might do something they want?

Because they think an OS should be able to.. oh, I dunno.. run software?

Because they want to choose software for themselves, not leave the decision to some central committee that will tell them what options they're allowed to have? [1]

Because you've got the question precisely backwards, and the one that really matters is the user's question of, "does this OS/distro let me do what I want?"

Let's face it, if the answer to that question is, "no," you can pretty well forget about the world beating a path to your door. But that's okay, because apparently you don't want them there, anyway.

Stupid damn users.. thinking they should be allowed to choose software..

[1] - Seriously dude.. drop the "why can't they just do what we tell them to" meme.. NOW. Friends don't let friends evolve into spokesmen for the RIAA/MPAA.

Applications Packages

[SultanCemil]

If only major linux distros would use Application Packages like OS X, the world would be a better place.

Seriously, drag-n-drop installation rocks.

Re:Applications Packages

[croddy]

The reason Linux distributions have not been trembling to adopt the OS X style of package management, if you can call it that, is that it would be a poor fit for the Linux software ecosystem.

The vast majority of software used on Linux systems is licensed under the GPL; what is not is almost always under another license permitting free redistribution. This gives Linux distributors great freedom in selecting and assembling a compatible collection of versions, tested and working with the same versions of dependent libraries. In a larger distribution (such as Gentoo, Debian, or Fedora), most of the software you will ever need is already a part of the OS -- you just need to use the built-in package management tools to summon it from the distributor's repository.

OS X-style package management is best suited for a software ecosystem in which users draw software from a large number of heterogenous third-party sources, while the core OS and iLife suite are maintained and updated by Apple. A third-party distributor who wishes to distribute something that must link against a particular version of a library can include it in the application bundle, knowing that the exact version needed will be available. This can lead to many copies of the same libraries being installed, facilitating compatibility with applications that require different versions, but consuming (small amounts of) disk space unnecessarily and increasing the attack surface when multiple copies of an exploitable library are installed on the system. A system such as APT does not need to provide a facility for private copies of libraries, since it does all of the dependency computation, and all software in the repository is built and linked against the libraries in the repository.

Certainly, once you have resigned yourself to visiting a third-party distributor's web page, manually downloading a binary package, and then manually installing the binary package, drag-and-drop installation is very convenient. But the Linux software ecosystem does not require this concession from the user -- the Linux distributor is free to provide a repository and tools for finding, installing, and updating software, without the need for manual installation.

Re:Applications Packages

[Ash-Fox]

If only major linux distros would use Application Packages like OS X, the world would be a better place.

Because you can't install RPMs on DEB syste.. Oh wait, you can.

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.

Re:Applications Packages

[AKAImBatman]

As does clicking on a checkbox. Seriously, I don't need it to be any easier.

Unless the software you want isn't in the Synaptic repository. Then it's hell on earth for the average user. The only response they get from support and developers is, "Why would you want to use software that isn't in the repository?"

Actually, that's not true. There are plenty of other fun responses:

"You should compile it from source."
"The vendor should spend his time getting his software added to our respository!"
"Use RPMFind. I'm a developer and I've never had a problem installing binary packages on the distro I work on." (Conveniently ignoring that when something breaks, the "developer" fixes it himself.)

Not that there's much point in harping on this again. I'll just get the same, "U R STUPID", "You need to try distro XYZ", and "Everything is in my distro's repository!" answers I've gotten before.

Blinders on, and full speed ahead cap'n!

Re:Applications Packages

[Overly Critical Guy]

OS X style bloat? How about Linux style bloat. If you run Firefox, OpenOffice, GIMP, and KIllustrator, that's four entire windowing libraries and widget sets loaded into memory including libraries from two different desktop environments.

I love your evidence though. "Appears to require 4GB of ram." Right, dude. Right.

Re:Applications Packages

[jrockway]

But wait, if you run Firefox, OpenOffice, GIMP, and KIllustrator on OS X, it requires *5* entire windowing libraries.

Re:Applications Packages

[MrZaius]

To put it all in perspective, on my 400mhz g3 q/196mb ram, OOo in Linux w/gnome runs at a comparable speed to neooffice in OSX.

Re:Applications Packages

[be-fan]

There are substantial deficiencies with OS X-style packages, which would only be amplified in the Linux world. In general, OS X packages have to bundle libraries that are not included by default in the OS. This leads to anywhere from a little to a lot of wasted disk space and memory. The problem is limited in OS X, because there is a standard set of frameworks Apple ships with, but this is not true on Linux. As a result, app bundles would have to include things like GNOME as well.

Re:Applications Packages

[be-fan]

There is also another strength of package managers that the app-bundle system lacks. In OS X, apps will pester you to update them. Colloquy, which releases several times a month, gets really annoying in this regard. In OS X, apps have to do this because there is no way to update all apps automatically. A package-managed system doesn't have this problem.

Re:Applications Packages

[value_added]

OS X-style package management is best suited for a software ecosystem in which users draw software from a large number of heterogenous third-party sources, while the core OS and iLife suite are maintained and updated by Apple.

Reading the above (which, incidentally, is little different than the traditional Windows ecosystem) raises the question whether this defines what end users demand and expect of package management, which is that they can install anything and everything when and how and from wherever they want.

The article presents the issue as follows:

Mike Hearn ... claims that the project did not gain enough popularity ... because of the dominating doctrine which states that it's the distributor who should be responsible for the whole operating system. It is kind of similar to another popular opinion: that the administrator (root) should be responsible for the whole machine, and all the administrative operations should be preformed from a separate root account. These kinds of centralized management systems fit to the server market, but they don't really reflect the desktop reality that well. On desktops, the administration is only one of the roles the user plays and waiting for half a year for a new version of an application is often unacceptable. It is often a decade in the free software world! So if the "desktop reality" conflicts with the "server reality", then there may be a problem. I'm inclined to believe that, ignoring the comfortable niche of OS X, the above is mostly rubbish and the problem lies in the desktop reality itself. For example, I doubt anyone could disagree that the prevalent desktop reality of the Windows ecosystem has led to an unending stream of security issues facilitated in part by the bad habits of their users who are encouraged to be just that, desktop users, and similarly encouraged to be oblivious to the underlying reality that administration is a fact of life, irrespective of patience, laziness, or knowledge.

Personally, I don't see a problem with single or multiple centralised management systems, and I certainly don't see a problem with a root account. To say that what's good for the server is good for the desktop is simply redundant, ignoring the questionable premise that there exists such a distinction.

People are free to choose a distribution based on their particular needs and preferences. Perhaps they need to be reminded from time to time of the tremendous effort made on their part by the maintainers and settle for a less than perfect or ideal world?

Re:Applications Packages

[ElleyKitten]

Cause, meet effect. How easy is it for someone to create a closed-source application (Tool of the devil, I know) they charge money for (Anti-Christ! Burn!) and distribute it in a way that's easily installable on most linux systems?

Stick a deb and an rpm on a CD. Charge for the CD. You could also put it in a commercial repository. Linspire's CNR will soon be available for all the major distros, and it handles payment.

Re:Applications Packages

[bcrowell]

The reason Linux distributions have not been trembling to adopt the OS X style of package management, if you can call it that, is that it would be a poor fit for the Linux software ecosystem.
In addition to the reasons you mention, there are at least two other reasons why it's a poor fit to Linux.

One reason is that the typical Linux user is running 90+% OSS, while the typical Mac user is running 90+% proprietary software. The individuals and organizations distributing OSS are generally giving it away for free on the internet (although of course some people do pay money for free-as-in-speech software); since they don't have a revenue stream from the software itself, they have to keep their bandwidth costs low, and that means they don't want to serve up a 30 Mb binary, of which 28 Mb is someone else's libraries. Also, users who are downloading OSS don't want to download 30 Mb when they could download 2 Mb.

The other reason has to do with security. The standard Linux security model is that when a buffer overflow is found in a library, you just update the library, and the problem is solved. That doesn't work with statically linked binaries.

The five ways

[Harmonious Botch]

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.

How about we take the easy way out?

[khasim]

And that is ... define the requirements that the next generation package manager should have.

That way there is no need to worry about "replacing" the existing systems. You can instead focus on evolving them to meet the requirements. Even if each distribution/project takes its own path to get there.

#1. It must make installing new software as easy as it currently is with apt.

#2. The same for upgrading the software.

#3. The same for removing the software.

#4. The same for handling dependencies. Including the order in which dependencies must be installed.

#5. The same for validating the installed software against the original software (checksums or whatever).

#6. The same for re-installing the software over the existing installation when you accidentally delete or over-write something.

#7. The ability to point the updater at your own repository or multiple repositories.

#8. The ability to recompile (automatically) any software that you install for your specific hardware.

Anything else? Yeah, I know most of this is already handled with apt. But that's what I'm most familiar with. I keep seeing all the articles about "problems" but I don't seem to run into any problems on my server or workstations (and I'm running Feisty Fawn on my workstation).

Re:How about we take the easy way out?

[QuantumG]

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.

Re:How about we take the easy way out?

[seifried]

#1. It must make installing new software as easy as it currently is with apt.

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)

Re:How about we take the easy way out?

[wizrd_nml]

#1. It must make installing new software as easy as it currently is with apt.
#2. The same for upgrading the software.
#3. The same for removing the software.
#4. The same for handling dependencies. Including the order in which dependencies must be installed.
#5. The same for validating the installed software against the original software (checksums or whatever).
#6. The same for re-installing the software over the existing installation when you accidentally delete or over-write something.
#7. The ability to point the updater at your own repository or multiple repositories.
#8. The ability to recompile (automatically) any software that you install for your specific hardware.

...and it must do all of this without telling me what it's doing, because I don't care what it does as long as the software then works.

Re:How about we take the easy way out?

[srealm]

One more thing.

Make it easy to install software that has DIFFERENT dependencies.

The classic example I always give is LDAP - you either want it or you don't. However why should I install LDAP because some application decided to link against LDAP? Or conversely, what if the application was NOT linked against LDAP and I want LDAP support in the app (which is available in the app itself).

Unfortunately, the only real solution to this is source based installs or having a compile for every combination of dependencies. But possibly something that will allow you to specify dependencies, and if you break from the 'blessed' dependencies, still has the ability to compile the base version (with no extra steps required by the user apart from saying 'yes, OK, do the compile'). Without requiring it to recompile ALL packages involved (ie. if the LDAP is coming from some library used by the app you requested to be installed, it should only recompile that library, not everything or the final app (since its using shared code and not using LDAP directly).

And as an addition to that, there should be a way to 'offshore' said building to a build server (or servers) - that will keep the package once built (with record of its dependencies) - so that if you are deploying on a large scale, you can use the SAME package manager that comes with the default distro on ALL your boxes, and install your package with custom dependencies (triggering a compile), and then when you install that package with the same dependencies later, it will just pick up the pre-built version, just as if it came from the official pipe.

These kind of problems are rarely solved at all by packaging systems, and usually installing from a source archive for a single package on a binary distribution is a pain in the neck - especially if you want to actually build from a source archive with ALTERED dependencies. Right now, only completely source-based distributions allow you to change dependencies, but then you need to pay the penalty of building EVERYTING (yes, Gentoo and such have their pre-built packages for large modules like Gnome or KDE, but you still end up building a lot).

Basically, I'm saying I could not really use a binary packaging system unless it had the ability to fall back to source altering its dependencies (which means the package needs to know HOW to compile disabling and enabling certain things (ie. configure flags), not just how to compile the same way the binary distro was made), and do so seamlessly and without forcing the user to go though 7000 additional steps or have intimate knowledge of how to compile an application. Remember, from the amdin's point of view, they just don't want to install LDAP unnecessarily, they don't specifically want to have to know how to recompile XYZ package to exclude LDAP support, or even if they know how to, want to have to do that for every package that is optionally supporting LDAP using manual procedures to disbale LDAP support.

This, and the fact that getting 0-day releases for certain packages when a new version comes out (sometimes a new release fixes a specific bug you have been waiting to be fixed) without having to recompile it all myself and break the packaging system or have to get more intimate with the packaging system than I want are the reasons I switched back off of Ubuntu and back to Gentoo. I tried Ubuntu because I wanted to see what life would be like without having to compile all the time - but in the end found I could suffer the compile (especially with things like distcc) to have a system the way I like it without extra crap installed because it happened to be compiled with support I don't need, want and will never use.

PreZ :)

Re:How about we take the easy way out?

[LesFerg]

You left out the parts that usually alienate new users;
- Link it into the menu/desktop system
- Also link in help or documentation, or at least a relevant URL

Even somebody who has used Linux for many years and feels comfortable with apt, rpm etc, can still occassionally be annoyed as all hell when an application is installed, then you have to go searching all over the web to find some basic configuration guide, let alone finding how to start the app.

In fact, maybe part of the packaging system could include linking in the wiki that everybody uses to tell others how they made the demmed thing work.

Re:How about we take the easy way out?

[ploss]

#10 - The ability for 3rd parties to create their own packages that have the same advantages as being in the repository. For example, I currently download xyz from SourceForge as a .deb, and have it install. Great. Why not provide some notification of a new version, like a link to an RSS feed inside the package file that is checked on every apt-get update? Why not list it in synaptic, adept, yumex, etc.? Also, make it easy for the developer.

#11 - The ability to have a user install their own package easily and transparently, under their home-dir (not applicable to all packages, of course.) Then, when that package is installed on the base system, it should also remove the user package and symlinks (/home/user/bin.) It's not cool to need root to run yum or apt, or require sudo privs when I just want to get something simple. This is especially important in a multi-user system.

Just some additional thoughts.

Re:How about we take the easy way out?

[wordisms]

Dude, until I can click on setup.exe, and it just works, and then there is an "Unistall Program" menu in the program folder on the program menu... I just don't have the time. I've used all 5 methods, and they are great for server management, but for general desktop use, people need click and run. Maybe CNR will take off.

Re:How about we take the easy way out?

[Chandon Seldon]

Why is there this obsession with the awful Windows package system? Have you legitimately used a repository-based system with a GUI?

Setup.exe + an Uninstall menu item is strictly worse than, say, the way packages work in Ubuntu. If you want to just distribute a package file and have the user double click to install, that works great. But... there's also a giant fully-supported package repository.

I guess it basically comes down to one thing: As they would say on Fark.com... "No you can't have Linux be an exact copy of your favorite version of Windows. Not yours. (Picture of pony)"

Re:How about we take the easy way out?

[davmoo]

Why is there this obsession with the awful Windows package system?

Because my 72 year old mother can, and does, install programs herself in Windows. If it requires anything more complex than "double click on setup.exe" or "double click on the program icon when you save it", you've lost her completely and I have to tunnel in to her machine or make a 125 mile drive.

In the course of my work, I use Mandriva, Redhat, and Slackware distributions (I have never been able to get everyone elses' darling Ubuntu to install on any machine I own or control). I would not dare let my mother install something on any of the three. Hell will freeze over in ice multiple feet thick before she would understand things like "differences in the file tree", version dependencies, etc etc.

Re:How about we take the easy way out?

[dosquatch]

...and it must do all of this without telling me what it's doing, because I don't care what it does as long as the software then works.

Why is this funny? There's nothing evil about a silent mode. It's called "ease of use". In fact, I was kinda under the impression that ease of use was the point of this article. If you like screens of text, set a verbose flag. If you like pulling wires, you can still build from code.

Or is the goal to continue to scare people away from widespread adoption?

Re:How about we take the easy way out?

[burner]

Sure, she can do the install, but what about getting updates and bug and security fixes? And what of spyware?

I much prefer (as do my sister and mother) the simplicity of going to the Applications menu and clicking the entry for "Add/Remove...". You can browse around or search for a particular program by type or name. Click a checkbox, click OK, it's installed, unclick a checkbox, click OK, it's gone from your computer.

Re:How about we take the easy way out?

[cortana]

Dear lord, no. Bad & outdated third-party documentation is the software world's biggest usability problem.

Software packages should *include* the upstream documentation. That way, the user gets correct documentation that matches the version of the software they installed. If the documentation is very large, it can go into a separate foo-doc package.

The other advantage is that people using the software offline can access its documentation. :)

Re:How about we take the easy way out?

[Blakey Rat]

No.

Number 1 should be:

Allow commercial and proprietary software the same distribution channels are open source software.

Until that happens, there will be no commercial software on Linux. Not only do current Linux package managers not facilitate the installation of commercial or proprietary software, but they are also designed in such a way so that installing a commercial/proprietary package is likely to break the package manager, requiring an extensive repair process next time you run it.

Linux will never have a strong software ecosystem unless commercial/proprietary software is allow to compete on an even keep with open source software.

Re:Nonissue

[rsmith-mac]

I understand that it would perhaps be more optimal if there was a single package format, but that just isn't going to happen

Then realize you're basically accepting that Linux will never make a significant dent in the Microsoft+Apple consumer desktop market. You may be able to compile the source code, the rest of us either don't know or don't care. Either Linux is going to be a OS for users, or a OS for geeks. It can't be both because geeks will try to escape a OS too user-centric, and users will escape a OS that resembles the inconsistency caused by groups of splintered geeks.

RPM gets a nod but....

[westyvw]

Debian and Ubuntu don't even get a mention on what they DO use? This article makes it sound like RPM is THE package management system. Give me a break, at least a mention that a similar package approach (and more successful IMHO) is used by the Debian etc.

Hasn't explored other packaging methods

[shermozle]

(while discussing RPM)

Still, a lot of other systems like Ubuntu, Debian, Slackware, Gentoo or Linspire do not use the RPM format and do not plan to incorporate it. What that means is he hasn't used any other packaging formats. Common mistake that people think RPM is somehow "best" because it's used by a few distros. Do some searches for "circular dependency RPM" to see why that's just not true.

Re:Hasn't explored other packaging methods

[DoubleRing]

Hear hear! I have mod points, but I'd rather post.

Circular dependencies, aka RPM hell, is what actually prompted me to make the switch from the Red Hat family to the Debian family. I used to be a pretty die hard Red Hat user. It used to be that Fedora was the cutting edge, back in the core 2 and 3 days. I would have those days when I would wrestle with the packages, but I just took my hits and moved on. Then Ubuntu came along, and I realized how much time I was wasting with that stuff. It "just works." APT is great (it's a pity POSIX decided to go for RPM). Gentoo's portage is really cool too, but IALAB (I'm a lazy bum--if you can't reconcile the acronym, then you probably shouldn't know what the missing word is).

Re:Hasn't explored other packaging methods

[Alioth]

Circular dependency hell?

So package foo depends on package bar, and package bar depends on foo.

All you do is:

rpm -Uvh foo.rpm bar.rpm

Circular dependency solved. The circular dependency 'problem' (it never actually really existed) was more of a problem of lack of good documentation than a problem with the actual 'rpm' program. However, this is a problem that was solved years ago - I haven't used a distro in the last 5 years that hasn't had a system like yum, up2date or apt which does all the dependency resolution for you.

Re:Hasn't explored other packaging methods

[cortana]

Not to mention https://bugzilla.redhat.com/bugzilla/show_bug.cgi? id=119185 which is still not really fixed.

goddammit

[scenestar]

We have apt and *.debs

I'm not in the mood for a holy war right now, but for fucks sake, Debian perfected package management a decade ago.

Re:goddammit

[Salsaman]

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).

Re:Nonissue

[oberondarksoul]

The diversity of packaging formats is definitely a nonissue, because EVERYONE has the source code... If I need some software that isn't already packaged for me, I grab the source code and compile it.

Most users don't know what compiling software is, let alone how to do it. While having the source available is absolutely a good thing, there needs to be an easier way for new Linux users to install software. With so many different formats, some specific to some distributions, some to others, and so on, it's almost impossible to keep track - if Linux is to gain more share on the desktop it needs to be more accommodating to new users, and the current situation frankly isn't.

The hard part...

[PornMaster]

The hard part, as I see it, is dependency management for upgrading software.

Eventually, with RPMs, for example, I end up getting to the point that I have to force something, which shouldn't ever really have to happen... but it does.

not really

[ArbitraryConstant]

The problem is not that everyone is willing to accept a solution that sucks, the problem is that the current solution of integrated package management rocks.

All I need to do is search for something in the package manager GUI, click the its checkbox, click "apply", and I'm done. It's even easier than downloading a dmg, because you've got to go out and find that dmg on the publisher's website, or versiontracker or whatever. I simply express a desire for that program to be available, and then downloads, installations, updates, etc are all handled by the package manager. This even works for proprietary software (eg I have Nvidia's binary drivers, Adobe's Flash and PDF reader, VMWare Player, etc installed through my distro's package manager).

The best solution is for the vendor to supply whatever they're going to supply in a tarball, and then let the maintainers figure out what the dependencies and so forth are.

"Roll-backs" or "back-rev'ing" would be good.

[khasim]

#9. Good point. Being able to easily roll-back an "upgrade" that didn't work would be a very nice feature. So I've marked this as number nine.

In fact, Ubuntu might be switching to the Smart Package Manager http://labix.org/smart/faq which seems to support this functionality.

I also left out ...

#10. Mark packages so that they will NOT be upgraded. The same as I can do with apt.

They don't care about the file ext., fix the list

[BillX]

Well, they all involve a long list of available programs you could choose to install (plus dependencies, etc.) Granted, some have meta-package choices, e.g. "workstation collection", but past that, it comes down to a dumfounding-to-newbies long list of packages whose developers tried really hard to come up with a clever acronym, name it after their favorite band/old Norse god/tropical fish's Latin name, etc., rather than something that gives some clue as to what the program actually does. Personally, probably the most off-putting thing my first time installing a Linux distro (besides hardware configuration, which has gotten much better since then) was a package selection dialog with thousands of entries like:

GRAPPLE - GNU Remote Authenticated Potato Peeler Library for Emacs

If the chosen package manager cleans that up, or at least moves it from Big Long List to the more fine-grained categories a la download.com, the first-time user isn't going to care whether the package is a tarball, .deb, or what-have-you (provided the installation doesn't barf)

Re:How about we take the easy way out?-Fallback.

[seifried]

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.

Re:Nonissue

[Lord Kano]

Either Linux is going to be a OS for users, or a OS for geeks.

Exactamundo!

Maybe this makes me a heretic, but I don't think that Linux should ever try to become a mainstream user OS. A part of the allure of linux is that it is hard. The learning curve makes users feel like they've achieved something by becoming proficient.

If you made a distro, how would you prefer to spend your time? Would you rather deal with "XYZ_lib_devel is out of date, we need a package for the new version." or "How do I get AIM, ICQ and Yahoo messenger to work?", "WTF is this GIMP thing? Is it like pulp fiction?" and "How do I install MS Office on this"?

LK

sigh...

[element-o.p.]

Why, oh why does everyone always have to gripe that "distro x doesn't do things the same way as distro y?"

Linux, unlike proprietary, closed source software is about choice. That's what I LIKE about Linux--I can choose the way that I prefer, be that how to install packages, which desktop environment to use, which CLI shell to use, if Linux boots into a CLI shell or if it goes straight to X-Windows, etc.

*BIG sigh* Why not ask the mainstream users?

[NeuroManson]

Look. If you want mainstream acceptance, then appeal to the mainstream. THAT is what will determine the best distro.

One of the previous episodes of Drawn Together put it best:
Spanky (to the TV Reviewer): No wonder you hate the show so much. You're everything we make fun of! You're a Jewish, conservative, pro-life, born again, overweight, Asian, homophobic lesbian broad who cuts herself!
Reviewer: So?
Spanky: So, maybe someone who doesn't happen to be a Jewish, conservative, pro-life, born again, overweight, Indian, homophobic lesbian broad who cuts herself might not be offended by our show.
Reviewer: I have every right to tell people what I think of your show.
Spanky: Yes! But people should know you're not our audience, asshole!

You aren't making an OS to appeal to the guy in the cubibicle next to you in the CS class in college. You're making an OS, by your own claims basically, to overthrow the evil overlords (AKA Microsoft, if you ain't got it yet). So why is this STILL a debate today?

Keerhist, I'm a furry artist, and even I recognize the concept of a limited market margin, but I don't spend my time in debates and having epileptic fits or Tourettes outbreaks in order to try forcing non furry fans to accept what I draw. Jeeze.

You want "checkinstall".

[khasim]

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.

Checkinstall http://www.debian-administration.org/articles/147

It's not the answer to all issues regarding installing from source ... but it does handle some of them.

What really depresses me is that debs, dpkg and apt, that's about the best anyone has done.

Any suggestions on what would make them even better?

Re:You want "checkinstall".

[cortana]

dpkg --root=$HOME --install foo.deb

That option also makes it easy to set up chroots.

A total load of bullshit, and here's why

[Overly Critical Guy]

My favorite thing in package discussions is when someone with an agenda towards a particular implementation writes out a list of steps. The alternative is always padded with extra steps to make it more difficult-looking while their favored implementation is reduced to look squeaky clean and easy.

You padded the Mac list with the following:

• "Open disk image that contains the program." - DMGs are auto-mounted by Safari.
• "Open Applications folder." - There's already an Applications shortcut on the Finder, so you just drag to that when the disk image window automatically opens.
• "Create new icon in dock." - The fuck? You don't have to do this
• "Have to recheck the site periodically to check for a update for a specific program" - Bullshit. This doesn't even have to do with package management, and it's an OS X convention for apps to auto-check for updates when they're run. You don't have to recheck any websites.

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.

Re:This issue MUST be solved

[pandrijeczko]

There are many ways software is packaged in the Linux world, I agree 100% on this issue. But I also know that until software becomes portable *across* distributions, chances of Linux gaining a foothold in Joe User's mind and on hid desktop will be continue to be illusive at best. This is not good enough.

You're making the somewhat dangerous assumption that a general policy of "one sizs fits all" is what the Linux user base both wants and needs - this is entirely incorrect.

For example, as an experienced Linux user, the last thing that I want is a single, binary-packaged method of distribution of software. I use a source-code based distro called Gentoo which means that I get to compile the stuff I run my way on the basis that, if something goes wrong with compilation (as it does sometimes) then it's up to me to try to work out why. But the advantage is that I get to optimize all my applications the way I want to, all of them (hopefully) linked nicely to system libraries as they should be.

Sure, this isn't the way Joe Public wants it but then if he wants something simpler then, great, good luck to him - use something simpler. I've used Ubuntu a couple of times and this seems to heve a pretty good package management mechanism which I guess is based on the Debian system. (Please don't flame me if I'm wrong here, BTW, but Gentoo is the only Linux I really use these days so I fully admit to not being up to speed on other package management methods.)

I have always wondered why bright minds, working for "free" and able to produce an OS that is giving corporations with big budgets a run for their money, cannot agree on how best to package software. To many users, we in the Linux world are still a bunch of jokes.

This has absolutely *NOTHING* to do with "agreeing" to anything and you have totally missed the point of Open Source. Open Source is about a single or bunch of programmers thinking that they have a neat way of doing something with software and then making that software available for others to improve. Ultimately, if you're looking for Open Source software to achieve a specific task, then you probably have a number of different applications to choose from which will achieve at least some of what you want. This view of the world is typified by Vi and Emacs, for example, both of which at their heart are text editors but can be extended in certain ways to do a whole lot more. Consequently, some people prefer Vi, others prefer Emacs, that's just what happens when people get choices.

Unfortunately, as things stand currently, you cannot come into the OSS world with a "Windows mindset". In the OSS world, you do not hand over some money and have a piece of shrinkwrapped software fall into your lap. Instead, you have to take some responsibility for your computer and what you run on it and there's an expectation that you take the time to research what's out there and decide what you're going to use and how you're going to use it. Nobody's forcing you to use Open Source - it's there if you want it but if you don't, then stick with Windows and enjoy it.

Linux and OSS is *NOT* a fashion statement - it's not about being "cool" or different. If you use either, then be an adult and accept the ramifications of that decision. OSS will not come to you, you need to go to it.

Sadly, it appears that because of bigotry, selfishness and ego, it will be a few more years before those that command authority in the Linux world wake up. I hope we'll still be relevant by then.

Sorry, but now it is quite clear you've lost it - you're now sounding like a bitter little man who's frustrated with Linux and/or OSS but is not prepared to put in some effort to helping himself.

"Bigotry"? Where? If you mean that certain people have rejected the Windows way of doing things and have decided to do things a different way, then surely that's their choice, isn't it? I really can't see how it's impacted Windows users in any way - apart from in a good way where OSS surel

No one really cares...

[aero6dof]

I'm only exaggerating a little here, but no one really cares about the packaging format per se. They care that the can find, download, install, and run a package without hassles. Most formats take care of the mechanics of that process, but still need a community of people to track down and fix issues - mostly inter-package issues. Rpm and deb both have that kind of community behind them (both with sub-groups). If there is any technology to be improved here, it should be making package repositories better and reducing the workload of the supporting communities.

Re:Ubuntu

[deek]

Why is Ubuntu in that list? I may be misinformed, but it was my understanding that Ubuntu was based off of Debian.

  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.

MOD PARENT UP

[QuantumG]

Yes, very good point. Forgot that one. Sometimes I actually think every user should have their own unionfs for / then they could write anywhere they want, change any configuration file they want, etc. Of course, when the su or sudo their unionfs goes away :)

Re:Possibly.

[QuoteMstr]

Such functionality would probably be beyond the basic options of installing an unpackaged app from source code. But there's no reason that additional information couldn't be included with packaged apps detailing the more common options.

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.

The fewer apps you're running, the fewer avenues of attack there are for you to be compromised. This could be a great feature for securing boxes.

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.

Re:Nonissue

[zzatz]

"...never make a significant dent in the Microsoft+Apple consumer desktop market."

Linux will never make a significant dent in the Microsoft+Apple market by doing the same things the same way as Microsoft and Apple.

Look at markets where Linux has succeeded, such as servers and embedded systems. Linux succeeds *because* it doesn't follow the Microsoft license model, the Microsoft development model, the Microsoft business model, and so on. You can't win if you play by Microsoft rules.

Linux can be, and is, an OS for users. It isn't an OS for third party closed source binary distribution. Don't read that as non-commercial; commercial software was distributed in source form before Microsoft and will be again. Distribution in binary form makes sense for games and art, but not for general purpose computing. The value of doing things in software rather than in hardware is that software is malleable. But you need the source to realize the full value; binary distribution removes value.

So yes, Linux will not make a significant dent in the Microsoft+Apple consumer desktop market, if that means the closed binary sales market. If Microsoft played in the NFL, they'd be the Super Bowl winning Colts. But the Colts will never win the World Cup, which is worth more. Don't complain about Linux not hiring a bigger front line when the game Linux is playing is soccer, and doing rather well at it.

Re:That crap in Suse 10.1 sucks monkey nuts

[gbobeck]

Gentoo will never be mainstream until it supports a user friendly installation method like Vista's MSI files.

I respectfully disagree with your statement.

1. Gentoo already has a (somewhat) user friendly installation method. For packages, it happens to be called 'emerge'. For the Gentoo install itself, there is a graphical installer. Now, if someone out there would like to create a GUI interface to emerge, that would be cool.

2. Gentoo doesn't really care about being mainstream. There happens to be a fairly large group of users who like bleeding edge. Gentoo is bleeding edge. Some people want to rice out their make.conf. Gentoo makes it easy for you to annoy everyone by ricing out your make.conf. (Hey, don't laugh, but all of my ricer settings in my make.conf file have really improved my server's performance by a whopping 0.0003%. That increase in performance makes doing absolutely nothing at idle go so damn fast!)

By the way, .MSI is a (poorly) reversed engineered version of the InstallShield Installer.

Re:That crap in Suse 10.1 sucks monkey nuts

[pandrijeczko]

2007.0 should be out soon but I'm going to go ahead and load up with 2006.1 for now.

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.

Re:Nonissue

[HBI]

Not very popular around here, apparently, but i'd much rather it stay a geek OS.

It's nicer that way.

Defective by design

[Wiseman1024]

The need for package managers in Linux is a consequence of a desgin defect. First, there's the "lol freedom" philosophy of not having one, two or even three different OS setups and layouts, but a gazillion of them, which causes trouble.

Second, there's the FHS, which is the worst idea to ever make it to Unix. You spread your application files like you deal cards in some card games, being completely unable to copy or relocate them, pack and unpack them effectively, or install several versions of the same program, besides being illogocal and semantically wrong in many parts.

Third, there's the defective LD_LIBRARY_PATH behaviour that makes "." mean the launch directory, not the application directory (holy retarded idea, Batman!). This means you can't rely on putting copies or hardlinks of the required libraries in the application executable directory to keep everything using the right libraries and versions and make them easy to distribute. This led Mozilla to find a workaround with a shell script. When you run Firefox or Thunderbird on Linux, what you're running is a shell script (requires an extra sh instance) that properly sets the environment for the software to be able to use its own libraries regardless of the crap you may have in your FHS "boxes of random crap". Consequently, software like Firefox and Thunderbird do not require a package manager (in fact, PMed versions of them are usually spoiled and crappy), and can be safely copied, relocated, or made to coexist with other versions.

Its very simple

[Stevecrox]

Installing things in Linux is confusing and hard to a new user (be they computer iliterate or not) Windows has an incredibly easy installation system that even complete novice's can understand, OS X has a simple way of installing that people can understand.

Linux has 5, none of them simple. Give me something simple that doesn't involve typing sudo something, something and I'll take to it. Why should I have to deal with the source code at all? I get open source products in windows I get an installer than installs the application and puts the source files into a folder for me. I like that.

you guys may love the various install methods but give me and average joe a simple way to install and get used to the OS first.