The Future of Packaging Software in Linux

[ Saturday, 17 February 2007, kocio ]


GNU/Linux is known for its diversity and freedom of choice. There are multiple window managers and desktop environments, many competing systems for handling sound, graphics and hardware autodetection. This diversity is the power and weakness of free software. Exactly the same problem concerns installing software in GNU/Linux. There are currently at least 5 popular ways of doing it:

  • Installing directly from source code,
  • 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,
  • Installing from distribution-specific packages like different versions of RPM, DEB, TGZ, and other packaging formats,
  • Installing from distribution-independent binaries (most proprietary software is delivered this way),
  • Using another distribution-independent system like autopackage, zero-install or klik — none of them gained a significant market share so far.

This situation is not a problem for experienced users — they can make decisions about choosing the best way of installing software themselves. However, for a newcomer in the GNU/Linux world, this situation is pretty confusing. In this article I am going to sum up some of the recent efforts to fix this problem and examine the possible future of packaging software in GNU/Linux.

Package formats wars

The war of packaging formats in the GNU/Linux world is reaching its peak. The developers of competing formats are doing their best to convert as many distributions as possible to their products. Here is a short summary of the latest activities in this area.

RPM unites

Red Hat Magazine has published an article called The Story of RPM about the history of RPM package manager. It used to be a very strange product. Its ancestors: RPP, PMS and PM were separate projects with similar goals. When RPM arrived, replacing the former standards, it was first being developed under the same name by many GNU/Linux distributors independently, causing a lot of confusion and interoperability problems. Recently, this situation has changed and the major distros (those basing on Red Hat and using RPM) decided to unite and work together on the development of RPM. It’s great news for the distributions like Fedora, PCLinuxOS, Mandriva or openSUSE. 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.

Autopackage slowly vanishes

Autopackage, one of the recent efforts of developers to standardize packaging in GNU/Linux has not been very successful. Despite a promising debut and even providing a stable 1.0 release (the most recent version is 1.2.1, Autopackage is dying. The programmers (actually only one is actively working on the project) believe that the lack of success of the project is caused by the reluctance of Linux vendors who are well accustomed to the current status of distro-dependent package systems and don’t want any change.

It may also be that Mike Hearn — the project founder, now a Google employee — is right. He claims that the project did not gain enough popularity (and none of the distribution-independent packaging efforts did, actually) 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!

“I eventually concluded that Linux was never going to make the big improvements to desktop computing that I wanted to see, and, therefore, that it’d never get non-trivial market share. That’s one reason why these days I work on servers for Google instead of client-side stuff for a Linux company.” — Hearn concluded.

Conary approach

Another interesting approach to packaging is presented by the Conary team. Conary is a mixture of a package manager and a version control system. This tool has gained the acceptance of a few vendors and it is feasible that it will be adopted in those systems in one form or another. It is however no revolution since it does not resolve the biggest problem — the incompatibility of the current solutions.

Where does the future of packaging lie?

As far as freeing the packaging from the distributor is concerned, there are at least two directions possible. The first is the wide acceptance of the refreshed CNR (Click-And-Run) system, which is going to support all the major GNU/Linux distributions in the near future (and in time, even more platforms). The plans to make the development of CNR more open creates a chance to gain the community and finally — the vendors. Currently only Linspire and Ubuntu (from version 7.04) support the system, but if few other major distros accept it, it may be enough to spread the new de-facto standard in the Linux world, since most of the distributions are Debian, Fedora, Ubuntu, Mandriva or SUSE-based anyway.

Another option is the fast evolution of LSB’s Linux Standard Desktop Project. Linux Standard Base may help to standardize at least the versions of the core libraries used in the major distros making it much easier to produce general packages in the future. It seems to be a serious option since LSB is already widely adopted in most distributions and the fact that the LSB guys chose to cooperate with the vendors instead of creating the new standard on their own works for the benefit of the standard.

Whatever the future if packaging will be, it is good to see that the Linux vendors (seem to) have finally agreed that the current situation is not satisfactory and the future of GNU/Linux acceptance depends on standards, also the packaging ones. Hopefully, one will be formed in one way or another, soon.

More information

This text is based on a translation of article by Daniel Koć published on linuxnews.pl. I (michuk) added some personal thoughts to it (accepted by the original author).

Subscribe to RSS feed for this article!

67 Comments

fold this thread Software Download Rx  Sunday, 18 February 2007 o godz. 12:10 am #  Add karma Subtract karma  +0

So many more people use linux but it is so under-rated

(Comments wont nest below this level)
 
fold this thread tzbishop2k  Sunday, 18 February 2007 o godz. 4:11 am #  Add karma Subtract karma  +0

Do you think it’s really a good idea to have CNR installers standarized? I think it’s very practical to update the system with a apt-get dist-upgrade, for example. I think it would be practical too, if the user click on the RPM, DEB, whatever format, and it opens a GUI program to install it, as we already have on some distros.

(Comments wont nest below this level)
 
fold this thread michuk  Sunday, 18 February 2007 o godz. 11:18 am #  Add karma Subtract karma  +0

@tzbishop2k: You are perfectly right, but the idea of a standard is a bit different. The native package managers are going to stay anyway, so the best thing LSB can do it to help standarize the core libraries of the popular distros and thus make “package translation” useful.

If all major distros provided a specific version of most core libraries, preparing packages for the specific distros would not be necessary. The packager would only have to create one universal package (either DEB, RPM or something completely new), then import it to CNR and immediately all the users of all distros could then download it and use it (either via CNR or via an native platform integrated with it).

That’s at least my vision of what should be happening in the next few months.

(Comments wont nest below this level)
 
fold this thread whadar  Sunday, 18 February 2007 o godz. 12:49 pm #  Add karma Subtract karma  +0

How about just running application and not installing at all?

You can run software from remote installed filesystem – see http://vamosproject.org/rootz

(Comments wont nest below this level)
 
fold this thread tbuitenh  Sunday, 18 February 2007 o godz. 3:36 pm #  Add karma Subtract karma  +0

Conary isn’t any more distribution independent than for example portage and deb are. A good example of a distribution independent system is zeroinstall ( http://zero-install.sourceforge.net/ )

(Comments wont nest below this level)
 
fold this thread steve  Monday, 19 February 2007 o godz. 7:44 am #  Add karma Subtract karma  --4

just use gentoo

(Comments wont nest below this level)
 
fold this thread Nicola  Monday, 19 February 2007 o godz. 8:12 am #  Add karma Subtract karma  +0

Why there is no mention about Debian packaging? It’s as used and popular as RPM, but much better in handling dependencies. RPM is NOT a standard. It’s one of many, and not the best either.

(Comments wont nest below this level)
 
fold this thread steve_0  Monday, 19 February 2007 o godz. 8:15 am #  Add karma Subtract karma  --1

frankly, I think apt-get/deb is great. I’ve never used Redhat to any appreciable extent, so I can’t comment, but I imagine that rpm has gotten to the same point. I think trying to come up with a new super universal package format is really just going to make yet another format and not solve many problems. Perhaps what is needed is a standard way of making commercial software that links to some open-source compatibility layer, and this layer can then be built for any distribution, and this whole package can be maintained like any completely open-source package, but the strictly binary parts are just pulled from the repository that way.

What I’d also like to see is a standard way for a user to install a binary software package in their home directory if the system administrator is unwilling to install it, but it would also use the system libs that were available, etc.

It would also be nice to be able to have multiple versions of packages installed without having different package names (why not just call the package python rather than python2.4 python2.5 etc, and have the ability for multiple version to reside), but that isn’t the current focus, and I really think this functionality should be morphed over from one of the current mainstream methods. Creating a new format, especially one without a distribution behind it, is going to help nobody.

(Comments wont nest below this level)
 
fold this thread Leo  Monday, 19 February 2007 o godz. 8:23 am #  Add karma Subtract karma  --1

I think that the best possible solution is to use apt-get, but with RPM packages instead of DEBs. We do this at Rutgers University (for Solaris 9) and it works great. DEBs are much more complicated to build than RPMs and RPMs only require the editing of one file (the spec file) to create. If more people were to use this solution, package managing would be greatly simplified and improved.

(Comments wont nest below this level)
 
fold this thread steve_0  Monday, 19 February 2007 o godz. 8:31 am #  Add karma Subtract karma  --1

I guess I’d like to clarify my above implicit point – vendors should be made to realize that compatibility is at the source API level, not at the binary API level. If they want to be able to release one package, probably the simplest way to do that and to not be a complete pain in the ass is to supply that stub source that can be compiled. Hard coded options such as configuration file paths should be in that source as well, allowing distributions, or whomever finally packages things, to set up the paths that make sense for their system, etc. I’d also like to see licenses for closed source software allow redistribution by third parties, so they could just go in normal respositories. Of course this all only really applies or helps the case of closed-source but free-as-in-keg-beer applications (like Skype).

I’d also like to mention that I ran a slakware -desktop- back in the day (kernel 1.2.13), lest you think I’m some Ubuntu fanboy who hasn’t used anything else (although I’m running Ubuntu now and frankly I’d gladly go home with it after the show – if only I could get a backstage pass)

(Comments wont nest below this level)
 
fold this thread drfindley  Monday, 19 February 2007 o godz. 9:09 am #  Add karma Subtract karma  --2

Has anyone used archlinux? Seriously the best package manager. It’s simple and direct, really good at resolving dependancies, and doesn’t have a convoluted way of operating like apt-get, yum, deb, or rpm.

(Comments wont nest below this level)
 
fold this thread mmmmm  Monday, 19 February 2007 o godz. 9:32 am #  Add karma Subtract karma  +1

@drfindley: Actually while arch’s ‘pacman’ was good, I found the dependency handling was far from good. Most of the packages were broken, and often missed out dependencies, which you would later have to install after finding the program would not start due to missing libraries.

apt and dpkg actually check all the dependencies, as most of the build environments for packages built by Debian are done in clean chroots, so a broken package is quickly found as it won’t compile on their compile farm, as they did not explicitly specify a certain dependency.

Seriously, apt-get isn’t hard, if you can manage pacman, then you can handle apt.

yum I have serious issues with as it’s highly inefficient, with 10MB index files PLUS having to download metadata files for the RPMs.

(Comments wont nest below this level)
 
fold this thread Xama  Monday, 19 February 2007 o godz. 9:40 am #  Add karma Subtract karma  --1

Use Ubuntu and you won’t go wrong … APT APT APT … all the way …

apt-cache search HELP!

(Comments wont nest below this level)
 
fold this thread DaVince  Monday, 19 February 2007 o godz. 9:57 am #  Add karma Subtract karma  +1

What about gobolinux? The solution proposed is to rethink the linux file system structure: one directory per package. In this way, the package management is simplified and can be done without the help of any fancy software.

have a look at http://www.gobolinux.org/

(Comments wont nest below this level)
 
fold this thread Bojan  Monday, 19 February 2007 o godz. 10:15 am #  Add karma Subtract karma  +0

It’s not linux, but pcbsd has download and install from single file. Unlike klik, you can download file while in windows.
http://www.pcbsd.org/

(Comments wont nest below this level)
 
fold this thread hicelik  Monday, 19 February 2007 o godz. 10:43 am #  Add karma Subtract karma  +0

Pardus linux and its “pisi” package system is great. Pardus software repositories contain all necessary software pre-packaged. They have quick and fast download servers.

http://www.pardus.org.tr/eng/index.html

(Comments wont nest below this level)
 
fold this thread Graham Murray  Monday, 19 February 2007 o godz. 11:13 am #  Add karma Subtract karma  --1

I think that specifying versions of the core libraries is a bad idea. Such things nearly always have a lot of momentum, taking a long time for the standard to be updated to specify a new version. This would lead to stagnation and a considerable slowing of innovation.

(Comments wont nest below this level)
 
fold this thread AJS  Monday, 19 February 2007 o godz. 11:26 am #  Add karma Subtract karma  +0

I’ve tried Debian and Gentoo, and there’s really very little to choose between apt and portage. Debian packages are precompiled and require separate -dev packages; Gentoo ports download as source and compile on your machine. You can also download Debian packages in source form, though.

The only RPM-based distro I’ve tried was Mandriva, back when it was called Mandrake. I soon learned to forget RPM altogether and compile everything from source :-)

IMHO, compiling the source code on your own machine (or maybe rather, having that automated for you; not that I think there is anything hard about typing “./configure”, “make”, “su” and “make install” in that order) is the way it should be done in future — binary packages belong at the bottom of the dustbin of history along with the problems they cause. If you could arrange it so that *only* programs compiled on your machine could ever be run on your machine, then it would be a lot harder for malware to spread.

(Comments wont nest below this level)
 
fold this thread sage  Monday, 19 February 2007 o godz. 11:33 am #  Add karma Subtract karma  +1

Maybe the requirements of server administrators (who want full control of all policy decisions and local copies of everything. Ever heard of internal revision?) and desktop users (who want is easy and working, never mind that somebody else is making sure all my packages are up to date and working together) are too different. Why force a package manager on two seperate groups? May be the solution _is_ two very different systems (I currently would propose RPM and Portage)

By the way, the LSB allready has decided. It requires RPM to be installed. Exactly the reason why there is a rpm package for Debian.

In the server world, installing from source is not a solution, as soon as you have to supply various options and take manual steps to install the software. Not quickly reproducable and documentation on how it is done is allways out of date. The package definitions will document the steps to such a point that a computer can do it.

mfg lutz

(Comments wont nest below this level)
 
fold this thread ivucica  Monday, 19 February 2007 o godz. 11:45 am #  Add karma Subtract karma  +0

RPM and DEB are comparable — APT-GET and whatever-redhat-produced are not. I prefer Debian-style. Gentoo’s way looks great to me, too, but I have not tried it so I can’t speak about it.

(Comments wont nest below this level)
 
fold this thread Matthew Bradley  Monday, 19 February 2007 o godz. 11:58 am #  Add karma Subtract karma  --1

There is already a single, standard way of installing software across linux systems – compile it from source. Why people demand that Linux becomes more like Windoze is frustrating. They want it spoon fed, rather than just picking up a book and learning a couple of commands.

I’m a big fan of Ubuntu and the apt system (Debian based package manager). It’s proven itself to me over the last 18 months. I use that for an easy life.

(Comments wont nest below this level)
 
fold this thread Malcolm Dugdale  Monday, 19 February 2007 o godz. 12:14 pm #  Add karma Subtract karma  +1
(Comments wont nest below this level)
 
fold this thread Gary Stidston-Broadbent  Monday, 19 February 2007 o godz. 12:35 pm #  Add karma Subtract karma  +0

I may be a little biased here as I use gentoo but, as far as I can tell portage is the only solution that will work.

Standardising versions of core libraries and software is not an option as this means that the compile flags would have to be standardised, leaving bloated systems. Why should I have to install X11 to install php just because the distributer compiled php with xpm support? This always leads to problems with people installing with options like –nodeps, an option that should not exist in my optionion!

The only way is if the packages are compiled on the go. This gives you the ability to customise your flags, and in doing so, the requirements related. Each distro could still create use flag templates for different installation options eg. Desktop install would include x11 flag. They could also have default binaries to quicken the installation time using the same method portage uses for binary packages.

(Comments wont nest below this level)
 
fold this thread Robert  Monday, 19 February 2007 o godz. 1:14 pm #  Add karma Subtract karma  +0

“[...] 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.”

And why should they? Three of these 5 examples are in fact of the same ancestry: Debian, and thus they use the DPKG format. DPKG ist (in my experience) vastly more powerful than RPM, and that is exactly the reason the Debian-based distributions did not and will not adopt RPM, although there is now at least an apt port for RPM, afaik.

Gentoo, on the other hand, never used a binary package format as primary distribution system and probably never will, because the distribution’s philosophy always was, still is and will probably stay “use the source, Luke”. That is like taking a vegetarian as example of people not eating veal: nevermind that he does not eat meat at all, that sill means he is not eating veal, right?

I am also very puzzled at the positive bias towards click’n'run. CNR is a formerly commercial effort by Linspire, and thus it is not suprising it only used to support that distribution. Since Linspire switched to Ubuntu as its basis, naturally CNR will work there without major problems. What I do *not* see, however, is CNR getting wide acceptance. It is an apt-based system, so as an Ubuntu user able to use the “Adept” or “Synaptic” GUI, I gain almost nothing by using it. So why should I?

(Comments wont nest below this level)
 
fold this thread liquidat  Monday, 19 February 2007 o godz. 1:19 pm #  Add karma Subtract karma  +0

When you write about such an important topic you should include the current situation of the important foundations around Linux as well:
The LSB launched a new discussion and initiative around that topic in December: they put all important people (RPM, deb, etc.) in a room to share their ideas but also to identify the real problems. Ian Murdock wrote some pretty good articles about that and this article should have included at least links to that statements:
Software installation on Linux: Today, it sucks (part 1)
Software installation on Linux: Tomorrow, it won’t (with some cooperation) (part 2)

(Comments wont nest below this level)
 
fold this thread michuk  Monday, 19 February 2007 o godz. 1:23 pm #  Add karma Subtract karma  +0

I am also very puzzled at the positive bias towards click’n’run. CNR is a formerly commercial effort by Linspire, and thus it is not suprising it only used to support that distribution. Since Linspire switched to Ubuntu as its basis, naturally CNR will work there without major problems. What I do *not* see, however, is CNR getting wide acceptance. It is an apt-based system, so as an Ubuntu user able to use the “Adept” or “Synaptic” GUI, I gain almost nothing by using it. So why should I?

You probably won’t but the newbie users will. CNR is easier than Synaptic and Adept and it will be probably integrated with the website as well, so you will only need to click some link on the WWW to install an application. Does it remiond you of Windows? Surely it does and this is the intention.

CNR is planned to support RPM-based distros as well, including openSUSE, Fedora and Mandriva. No idea how they are going to achieve this, though, but if they do, it may be a great thing for the begginners — one unified GUI (system) for installing software in GNU/Linux, whichever distribution they try — seems attractive, doesn’t it?

(Comments wont nest below this level)
 
fold this thread Soumyadip  Monday, 19 February 2007 o godz. 1:50 pm #  Add karma Subtract karma  +0

I’m really surprised that Klik didn’t receive a mention here. I don’t know if anyone has cribbed about it in comments before me, but I think the author should have included at least a line about it as an update.

(Comments wont nest below this level)
 
fold this thread michuk  Monday, 19 February 2007 o godz. 2:10 pm #  Add karma Subtract karma  +0

I’m really surprised that Klik didn’t receive a mention here.

It actually is mentioned as one of the distribution-independent systems together with zero-install and autopackage.

(Comments wont nest below this level)
 
fold this thread Matthew Tippett  Monday, 19 February 2007 o godz. 2:48 pm #  Add karma Subtract karma  +0

To help with packaging, until the market changes it’s approach, a meta package process is probably the only thing that would work.

AMD’s driver installer has an embryonic form of that approach. The packaging scripts apply the distribution’s policies, and allow either package or tarball approach to installation.

If the distribution is going to package itself, you may as well have a policy layer that the distribution can feed into to allow the packaging to happen automagically based on a 2-level heuristic.

The application provider registers intent in the high level meta-package, the this is converted to the native packaging format below. Distribution vendors can ‘add value’ through affecting the lower section of the instal mechanism.

(Comments wont nest below this level)
 
fold this thread guest  Monday, 19 February 2007 o godz. 3:35 pm #  Add karma Subtract karma  +0

“One directory per package” might be a nice alternative to RPM, but it doesn’t solve half of the problems that advanced package managers like APT deal with. It’s not a matter of where stuff is installed — even unzipping an directory on windows, going into the directory, and running the exe on windows fixes that. The big problem is how it all interacts, especially over time — how 50 packages are installed that another one needs, what happens when you ask for two packages that have conflicting needs, how upgrades work without rebooting, how new versions of your OS can be installed, even if they have new architectures or policies, etc. APT handles all of this. It should be the Linux default, at least until something better comes along.

(Comments wont nest below this level)
 
fold this thread Tweetiepooh  Monday, 19 February 2007 o godz. 3:59 pm #  Add karma Subtract karma  +1

I too wish that linking is not (as far as possible) made to specific versions of libraries.

Linking should be made to library.so which acts as a symlink to the real file, maybe through various levels of link.

eg requires libmy, libmy.so -> libmy-2.so -> libmy-2.20.so

Now one can link to libmy.so, or libmy-2.so (major version level) and only to libmy-2.20.so if that particular patch version is needed.

I’m sick of packages not installing because I have libmy-2.21.so installed and software is linked to earlier version. (I can understand if it needed libmy-1.so but that can be installed independantly of version 2.)

(Comments wont nest below this level)
 
fold this thread Stan Klein  Monday, 19 February 2007 o godz. 4:56 pm #  Add karma Subtract karma  +0

You probably should have included the Python language-specific distribution scheme using “eggs” and easy_install. There are a lot of Python programs released for Linux, and many of them are distributed using eggs (which are compressed Python script modules). The rpm-building features of Python distutils are broken because of broken aspects of RPM.

(Comments wont nest below this level)
 
fold this thread John Nilsson  Monday, 19 February 2007 o godz. 4:58 pm #  Add karma Subtract karma  +0

I see two components that should take us a great leap forward.

1. Design and implement a protopackage infrastructure that will help concentrate as much distroagnostic packaging work in one place and that provides every feature the distros need to ease their packaging of the software.

2. Make packages depend on interfaces not on packages.

(Comments wont nest below this level)
 
fold this thread mario  Monday, 19 February 2007 o godz. 6:28 pm #  Add karma Subtract karma  +0

Symptom fixing syndrome. Before the Linux community could even think of unifying the package manager or install UI, we’d at least needed to “freeze” some APIs (future & backwards compatibility) and agree on package naming and splitting. RPM and DEB (the formats) are pretty similiar, the package managers are different (dpkg is more user-friendly, btw). It would be trivial to make rpm or dpkg support both RPM and DEB, or TGZ, and with some effort even “ports” or plain source tarballs later on. However, there are more important things to standardize first.

(Comments wont nest below this level)
 
fold this thread DEF  Monday, 19 February 2007 o godz. 6:30 pm #  Add karma Subtract karma  +0

Checkinstall rules.

(Comments wont nest below this level)
 
fold this thread rick  Monday, 19 February 2007 o godz. 7:05 pm #  Add karma Subtract karma  +0

What about Gentoo’s Portage, and Debians Apt-get?

Those are two very fine package systems.

(Comments wont nest below this level)
 
fold this thread MrUbuntu  Monday, 19 February 2007 o godz. 7:24 pm #  Add karma Subtract karma  +0

The solution is easy:

setup.exe (it’s Linux equivalent)

95% of desktop computer users (assuming this really IS Linux’s target market) understand, nay, expect this approach.

If Linux ever wants to move beyond the .5% desktop market share, it needs to think beyond techies and hackers.

Even your grandma understands “setup.exe”…if, like most of the world, she’s been using a Windows computer.

MrUbuntu

(Comments wont nest below this level)
 
fold this thread jj  Monday, 19 February 2007 o godz. 7:25 pm #  Add karma Subtract karma  +0

Extremely poor article. Adresses non of the issues of software complexity, and other issues like granularity and dependency issues.

There exist a slew of problems with Linux packaging. They are another layer of complexity and dependency on top of Make – this is the reason I prefer the BSD ports. Packaging system dogma brought Debian to a halt.

The fact is, long ago, Unix developers thought out the portability issues. Unix is pretty portable…

Debian developers, for instance, would declare something depending on package x.y.2 when in fact, all the functions used existed in package x.y.1.

A better and more advanced concept is PC-BSD’s PBI. With PBI-packaged software, you just drag-and-drop (like Windows or Macs).

What the packaging people need is a whole theory of packaging.

(Comments wont nest below this level)
 
fold this thread Fred  Monday, 19 February 2007 o godz. 7:39 pm #  Add karma Subtract karma  +0

There is already a single, standard way of installing software across linux systems – compile it from source.

Believe it or not, some Linux users would actually enjoy to see some proprietary software being ported to Linux. However, software vendors don’t bother porting because the effort required is too big for the relatively small market share Linux has. If there was a unified BINARY way of installing software, then more vendors would do it.

For some people, a computer is about using the best tool for the job, and sometimes, a proprietary application is the best tool.

(Comments wont nest below this level)
 
fold this thread ringe  Tuesday, 20 February 2007 o godz. 12:13 am #  Add karma Subtract karma  +0

Even your grandma understands “setup.exe”

Bah, why would I want to run a wizard to install ONE single app? The Windows install philosophy plainly sucks. It’s hard to understand why users have to answer any questions at all except “what program do you want?”

Even grandma understands “Programs > Add/Remove…” in the menu of Ubuntu.

And about CNR: That’s hardly a “solution” to the proposed issues, since CNR just is a wrapper around DEB and apt.

The reason Autopackage and other nice propsals haven’t caught any market share is that it doesn’t go along with the rest of the distribution well enough. It could become a support nightmare.

(Comments wont nest below this level)
 
fold this thread Steve N.  Tuesday, 20 February 2007 o godz. 2:16 am #  Add karma Subtract karma  +0

As long as there is no uniform installer for Linux, It’s popularity will never grow! This is the only reason I have
not made the commitment to Linux. You can serf the net and
find lot’s of programs for Linux, and you think great! Then
you try to install your down load and the wailing and gnashing
of teeth begins. And like everybody else you switch back to Windows! If you can’t figure it out, how can you recomend Linux to anybody else?

(Comments wont nest below this level)
 
fold this thread Solifugus  Tuesday, 20 February 2007 o godz. 3:00 am #  Add karma Subtract karma  +0

What about ISVs? Software makers or distributors from six months to a year to get their products to market. By then, GNU/Linux distributions have changed so much that patches are often required just to make them install and function Furthermore, the lifecycle of a software product needs to be 3 to 5 years for profitability. And, the market is already split by only being able to support the top one or two GNU/Linux vendors at one or two versions, in most cases.

This issue has been long close to my heart. Personally, I lean toward Autopackage. The Linux kernel is backward compatible right down to version 1.0 and therefore including libs is all that’s needed for long-term viability. Requirements of a so packaged program, let’s say “Blender” should require only a certain minimum kernel version and an LSB-compliant platform.

Matthew C. Tedder

(Comments wont nest below this level)
 
fold this thread Tolkan  Tuesday, 20 February 2007 o godz. 4:29 pm #  Add karma Subtract karma  +0

Anyone who is committed enough to learning how to use Linux will become proficient in the operating system and hopefully appreciate its uses. This article wouldn’t exist if “everybody else” was switching back to windows.

(Comments wont nest below this level)
 
fold this thread Jim  Tuesday, 20 February 2007 o godz. 4:32 pm #  Add karma Subtract karma  +0

I heard about this package manager call dpkg, and its frontend call apt-get. It heard it works well. It’s just waiting for a “Major” vendor to use it before it make it into articles like this.

(Comments wont nest below this level)
 
fold this thread Metal_ER  Tuesday, 20 February 2007 o godz. 6:19 pm #  Add karma Subtract karma  +0

Uh Jim … dpkg / apt-get / aptitude etc. are tools used in conjunction with Debian packaging .. quite common with Debian like distro’s. Wonder why they didn’t mention it above as it works quite nicely (just like RPM).

(Comments wont nest below this level)
 
fold this thread John W  Tuesday, 20 February 2007 o godz. 8:44 pm #  Add karma Subtract karma  +0

Debian’s dpkg system is used by its derivatives (such as Ubuntu and Knoppix), all of these being major distributions. It can hold more information than an RPM, simplifying conflict-resolution, and is easily generated from the latter.

The diversity of installation methods is a strength rather than a weakness. None are difficult to use and all work effectively. A small proportion of people might find the variety of options confusing, but such people are probably better off with the severely limited functionality of Windows anyway.

(Comments wont nest below this level)
 
fold this thread GL Williams  Tuesday, 20 February 2007 o godz. 11:43 pm #  Add karma Subtract karma  +0

“As long as there is no uniform installer for Linux, It’s popularity will never grow! This is the only reason I have
not made the commitment to Linux. You can serf the net and
find lot’s of programs for Linux, and you think great! Then
you try to install your down load and the wailing and gnashing
of teeth begins. And like everybody else you switch back to Windows! If you can’t figure it out, how can you recomend Linux to anybody else? ”

I used to think like you, in fact I just switched back to Linux because of a similar problem to what your talking about. How can you recommend a system that forces you to pay for a new license, when you already paid for it in your hardware.

I have a two Dells, two COAs and they aren’t worth a hoot when the system trashed, I replaced the hard drive and tried to install a legal copy of the program.

I went with Ubuntu. I pressed on past the dark screen (I have an ATI card – the drivers aren’t automatically installed – unless you get the Euro DVD) so you install on faith and with the lights out (non functioning monitor) till you get it to go. The commands are memorized now, and there are no problems once you get past that hurdle.

Not all the software works, thats for sure. I am using open office, some high end sound apps and thats about it. My ‘Windows compatibility layer’ as I like to call it is an older copy of XP I had kicking around taken from a laptop and made into a Virtual file. I had to learn that too. It wasn’t so hard.

Your right, you crash and you burn. I did that in windows more often trying to run sound apps that cost thousands of dollars, and still I was waiting and waiting for the version that worked.

In linux too you crash, you burn and you have pain. But you don’t pay, even if it does work. Huge difference.

(Comments wont nest below this level)
 
fold this thread Chris Hubbell  Wednesday, 21 February 2007 o godz. 4:57 am #  Add karma Subtract karma  +0

This seems like the same debate that Linux always reduces down to. The community thrives on its own diversity, and to the insiders it is fun to have choices and debates over what works. To outsiders, or those more interested in what they need to accomplish than how they accomplish it the choices are distractions. Gnome or KDE? Apt or RPM?

What I think gets overlooked is the complexity of really learning the depths of each packging system, and the costs of maintaining test suites, and development time. For large scale apps it’s frustrating and more expensive for a company to have to maintain multiple package revisions. But, it you’re going to release on Linux you need to cover both bases. When I think about the amount of customization our site has put into packages I’m thankful that I only needed to develop to one system.

In the end, the Operating environment does not exist to provide diversity. It exists to run applications. Diversity is a good way to bubble up the best, but at this point in Linux’ life span its time to start picking a mainstream standard. It’s fine for sideline and niche distros to do what works for them, and even to challenge the mainstream… But right now there is no mainstream.

This is a classic example of the two-edges of blade that is Linux’s development model. With crowd-based leadership you get an amazing percolator for finding solutions to problems and making the OS responsive to demand. But when two really good optons make it to the top no one is in a position to make the final decision and move on to the next challenge.

What VALUE (excluding academic and religious debate) is there in maintaining two separate mature packaging frameworks? Would someone really choose Ubuntu over RHEL because of its packaging system? No. If it’s not a key differentiator then it’s probably a distraction from getting more effective projects done.

I think Linux is going to hit a glass ceiling in the corporate world if it doesn’t pick a mainstream standard for both desktops and packaging. It’s not do or die, but it’s definitely a deterrent to growing market share.

(Comments wont nest below this level)
 
fold this thread Panzer  Wednesday, 21 February 2007 o godz. 4:17 pm #  Add karma Subtract karma  +0

The main problem here is not the packaging software, it the wrong perception of Linux! Linux is NOT an Operating System, it’s the CLASS of similar Operating Systems (called distributions or, for short, distros)! The fact that we have a multitude very similar distros is just because all of them contains similar software apps built from the same source tree. Therefore, You cannot compare Microsoft Windows XP against Linux, it’s like comparing one specific car make and model against the whole class, say SUVs.

No matter wether OpenSUSE, Fedora, Mandriva and RedHat ALL use RPM package manager, app made and packaged for, say, Fedora, will almost certainly NOT work with OpenSUSE – different dependencies, different versions of system libraries, etc. The only way an app can be guaranteed to work with all Linux distros is to build it as a static binary, with all dependant libraries either built in or packed with the binary itself, much like most of the Mac OSX apps are. It’s the way most commercial companies should go (and most of them do!) and in that case the way that app is packaged is less important (commercial vendors will most likely chose only a couple of ‘major’ distros anyway, because of support problems).

(Comments wont nest below this level)
 
fold this thread G Fernandes  Wednesday, 21 February 2007 o godz. 4:55 pm #  Add karma Subtract karma  +0

Package management is a method and process of delivering system updates and installing new software. Therefore, it is perfectly reasonable that the distribution in question provides this mechanism along with maintaining repositories of common software.

As one may note, this is no problem for GPL and GPL-license-compatible software.

This becomes a problem when ISVs wish to provide installable packages for a wide cross-section of GNU/Linux distributions.

This problem arises because the GNU/Linux distributions can not be expected to maintain package streams for binaries not under their control.

And, if you step back a bit, this problem is not exclusive to the GNU/Linux platform. ISVs have to be prepared to maintain packaging streams per supported platform. That is part of the software delivery cost. Sun Microsystems for example, delivers the Java SDK as a Windows installer, a RPM installer (which incidentally isn’t Red-Hat compatible, but may be used on other RPM based systems), a generic GNU/Linux binary installer, and other platform specific installers.

Of course, the solution is:
1. Use one of the generic, non-distribution-specific packaging mechanisms
2. Maintain one package stream per distribution mechanism

In either case, ISVs are responsible for packaging their software. In this case, each GNU/Linux distribution can be viewed as a POSIX compliant OS with a unique mix of software component versions – all GNU/Linux distributions do not come with the same version of GCC for example. This in itself classifies each GNU/Linux distribution as a potentially separate, albeit compatible platform.

It should therefore come as no surprise to ISVs that each distribution may require an independent packaging stream.

It is conceivable that the software installation/update services are abstracted into a standard, cross-distribution API. However, until that time, each distribution will have to be viewed as a potentially separate platform requiring an independent packaging stream.

(Comments wont nest below this level)
 
fold this thread dbneeley  Wednesday, 21 February 2007 o godz. 5:02 pm #  Add karma Subtract karma  +0

“I heard about this package manager call dpkg, and its frontend call apt-get. It heard it works well. It’s just waiting for a “Major” vendor to use it before it make it into articles like this.”

Jim–

What do *you* call a “Major” vendor? For several years now, by far the most popular distribution has been Ubuntu (and its variants Kubuntu, Xubuntu, and Edubuntu). It, like many others, is based upon Debian–and all of these use dpkg/apt.

While a considerable cleanup of the file structure is underway courtesy of the LSB project and many cooperating vendors, many of the packaging issues will become less over time. In the Linux tradition, the strengths of various approaches are being adopted by the major solutions. The resurrection of development in the RPM space should be testimony to that.

I have used RPM-based distros and have shifted to Kubuntu as my primary distro of choice. I find at present that dpkg/apt with its various graphical interface solutions to be far superior to the present state of RPM. However, please note that those who wish to also use RPM can easily install it.

(Comments wont nest below this level)
 
fold this thread michuk  Wednesday, 21 February 2007 o godz. 5:10 pm #  Add karma Subtract karma  +0

I heard about this package manager call dpkg, and its frontend call apt-get. It heard it works well. It’s just waiting for a “Major” vendor to use it before it make it into articles like this.

Uh Jim … dpkg / apt-get / aptitude etc. are tools used in conjunction with Debian packaging .. quite common with Debian like distro’s. Wonder why they didn’t mention it above as it works quite nicely (just like RPM).

Well it hasn’t been mentioned because there’s nothing interesting going on with APT currently. It’s simply good enough for the Debian-based distros and it’s simply not going to be accepted as a cross-distribution standard.

The future of packaging may be only a completely new meta-format that is going to work both for RPM and for DPKG/APT.

(Comments wont nest below this level)
 
fold this thread Bob Robertson  Wednesday, 21 February 2007 o godz. 8:19 pm #  Add karma Subtract karma  +0

I like that. “Nothing interesting going on with APT”.

Nothing interesting is going on, because it works.

(Comments wont nest below this level)
 
fold this thread Bob Robertson  Wednesday, 21 February 2007 o godz. 8:33 pm #  Add karma Subtract karma  +0

The biggest problem is not cross-distribution packaging, it’s getting people to _pick_ and distribution. Different distributions exist primarily because of different packaging systems, in my opinion. I also do not think this is a bad thing, it is just the way the world works.

There are different languages. There may be those who complain that not everyone speaks Japanese, but let’s also face the fact that not everyone in the world _wants_ to speak Japanese, or package in .deb.

Wakarimaska?

(Comments wont nest below this level)
 
fold this thread Joe User  Friday, 23 February 2007 o godz. 2:32 am #  Add karma Subtract karma  --1

As long as software developers will have the “Works for me” attitude, they will consider this is not a problem. In a previous thread I read that software installation isn’t a problem. Users are probably inventing a problem then? We could have said the same about package managers. Why should we offer a package manager if we can run a tar xvzpf firefox-2.0.0.1-x86.tar.gz after all? For the same reason exposed by short-sighted developers, I suggest removing Synaptic from Ubuntu and CNR from Freespire. And you should thank the developers who are kind enough for offering a tar.gz precompiled package of your favorite applications! So installing software on Linux is not a problem, not even for Eric S. Raymond. Autopackage and Klik are trying to fix non-existing problems. Real men use plain .deb and .rpm and resolve their own dependencies themselves!

(Comments wont nest below this level)
 
fold this thread Andrew  Friday, 23 February 2007 o godz. 6:27 am #  Add karma Subtract karma  +1

The comments on this article are mind numbing.

Everyone who is arguing that this topic isn’t relevant is insane. It will be amazing when Linux has a more standardized package management system. Using Linux applications will be so much easier when you have the option of using packages from anywhere (you trust) rather than choosing a distro based on the packages you need _now_ and having to compile the rest from scratch.

It’s projects to combine the efforts of packaging, desktop tools, and kernel/stability that will really advance Linux. Freeing all of the developers and administrators to work on other cool projects (projects which would be much more focused when they only have to work with a single packaging system/library/standard by the way) to make desktop and server management easier.

Poor “joe user” who is mad because developers tend to be introverts. You can find grouchy people associated with anything. Nobody is going to apologize for you encountering a certain personality — there’s plenty of room in the open source world for all of them, and at least he’s actually contributing (something that will probably be packaged later by a more “people person”). Not everyone has to care about user needs, plenty of the hard core coding that needs to be done is going to be done by the geeky personality… not to hurt your feelings, you _are_ special!

So, yeah, this is a very relevant topic and focusing on it will be a huge gain for the operating systems that take advantage of it. /rant

(Comments wont nest below this level)
 
fold this thread João Pinto  Friday, 23 February 2007 o godz. 10:18 am #  Add karma Subtract karma  +0

People should understand that CNR is just a service/interface, it uses the Debian package forma with APT repositories. The major advantage is the fancy interface and the commercial repository.
The CNR packages have the same features and problems of the Debian ones.
The news of CNR becoming available for Ubuntu is just marketing, because Linspire will be based on Ubuntu all their packages will need to be Ubuntu (Debian) compatible, not the way around.

(Comments wont nest below this level)
 
fold this thread Ian  Friday, 23 February 2007 o godz. 10:43 am #  Add karma Subtract karma  +0

I suspect that Linux will end up with two package installation systems. An old native in-house system (APT/YUM/URPMI/YAST/Smart/TGZ/Ports/Portage) used for updates, installation and distro-supported applications. The other system would be a universal 3rd-party system for vendors to use.

One possible solution would be being able to compile encrypted source code/byte code. If that could happen, 3rd parties could distribute the encrypted source (which would be machine-intelligible but human-unintelligible) and an auto-maker/compiler could configure, make and install the software. But it’s probably an unlikely thought.

A few ideas would be

A) Settle on where software is to be installed. Either ask the User or install to a set place determined on install. (desktop computers could get away with an /Applications file, while servers/business users would may want a /home/User/Appliation for each user.)

B) Discourage loosely linked applications. Applications should contain all libraries and programs needed to make that application work that doesn’t need an Distro to suprot. (It’s fair to expect someone to be running KDE or be using an ATI card. Those excitations should be communicated upfront though, like what’s listed on a boxed software’s System Requirements.) The installer should install all missing/non-exsitant library/program data, skipping over what’s already installed. The best solution to program dependency is to minimize or eliminate dependencies.

Until the user-base speaks with a super-majority voice asking for one system, unless the top 10 Distos collaborate or Linus or the FSF Use their authority to say “use this universal package manager”, I don’t expect a universal package manager. I would be nice.

(Comments wont nest below this level)
 
fold this thread Henrik  Friday, 23 February 2007 o godz. 10:47 am #  Add karma Subtract karma  +0

This combined with another article here (Five things to know when you switch to Linux) makes for a good first time linux user article.

(Comments wont nest below this level)
 
fold this thread Rene Rebe  Friday, 23 February 2007 o godz. 11:00 am #  Add karma Subtract karma  +0

In the BSD Port sysem a-like sucessors the T2 SDE Project can be added.

(Comments wont nest below this level)
 
fold this thread snoozzzer  Monday, 26 February 2007 o godz. 4:41 pm #  Add karma Subtract karma  +0

Just a little thing that’s been bugging me. BSD had ports, and then gentoo used the idea for portage

(Comments wont nest below this level)
 
fold this thread Nospam  Wednesday, 7 March 2007 o godz. 10:41 am #  Add karma Subtract karma  +0

I have been evaluating Linux distro one a year for ten years for use on a family desktop.
On January 2007 the unbilievable happened : I found out that Linux had reached the level of quality I expected from a modern OS on a desktop system (I never questionned the quality of linux on a server system).

However, there are three remaining concerns :
- the software installation mess. Come on, Linux developers. You cannot seriously expect to gain market shares on the desktop if you keep happy with forcing lay people either to ./configure, make, make install, make clean, either to find out or wait for distro-specific rpms, .deb or whatever.
- the copyright issues. One cannot expect acceptance of linux on the family market without a proper, out-of-the-box DVD and various codecs .avi reader.
- the game issue. We need games for Linux.

(Comments wont nest below this level)
 
fold this thread Felipe Contreras  Tuesday, 31 July 2007 o godz. 10:14 am #  Add karma Subtract karma  +0

I have thought on this for quite some time and I think there’s a lot of things to do. I’ll try to explain why I think so. I might make mistakes, specially with debian packaging system as I’ve barely used it; if I do please ping me back.

More here.

(Comments wont nest below this level)
 
fold this thread gangstar vegas hack les jeux de fille  Saturday, 24 May 2014 o godz. 2:23 pm #  Add karma Subtract karma  +0

Groucho Marx is at his best here, with his Firefly delivering so many great quick-fire lines that
you’ll believe he was vaccinated with a phonograph needle.
The ever changing nightlife of Las Vegas makes it one of the favorite spots for the tourists.
A healthy and comfortable sleep is very essential
for every living being as it helps us to recharge our body and mind.

During his time in prison Kuklinski granted interviews to psychiatrists, journalists,
and law enforcement officials, giving detailed accounts of his life as a contact
killer. Being a married woman, this femme that’s
into filthy things does her dirty work as a “beauty of the day” as opposed to the less-secretive “beauties of the night. Jack led a full life,” Satterfield, a Southern California high school activities
director and silent film buff, told the Sun.
Thus, practice of Hinduism in Arab countries depends on the
conservative nature of the country.

(Comments wont nest below this level)
 
fold this thread weakpointroulette  Saturday, 12 July 2014 o godz. 12:02 pm #  Add karma Subtract karma  +0

It is appropriate time to make some plans for the longer term and it’s time
to be happy. I’ve read this publish and if I could I want to
suggest you few interesting issues or suggestions.
Maybe you could write next articles referring to this article.
I desire to learn more things about it!

(Comments wont nest below this level)
 
fold this thread location appartement espagne  Friday, 18 July 2014 o godz. 7:17 am #  Add karma Subtract karma  +0

Wonderful goods from you, man. I’ve take into account your stuff
prior to and you’re simply extremely excellent. I actually like what you
have got right here, really like what you’re stating and the way in which through which you are saying it.
You are making it entertaining and you still care for to keep it wise.
I can not wait to read much more from you. That is
actually a wonderful website.

(Comments wont nest below this level)
 
fold this thread annonces plan cul  Tuesday, 23 September 2014 o godz. 1:12 am #  Add karma Subtract karma  +0

I read this paragraph fully about the resemblance of most recent and
preceding technologies, it’s awesome article.

(Comments wont nest below this level)
 
Name (required)
E-mail (required - never shown publicly)
URI

Adjust field size: shrink | enlarge)


You can use simple HTML in your comments. Some examples are as follows:
  • A hyperlink: <a href="polishlinux.org">GNU/Linux for everyone!</a>,
  • Strong text: <strong>Strong text</strong>,
  • Italic text: <em>italic text</em>,
  • Strike: <strike>strike</strike>,
  • Code: <code>printf("hello world");</code>,
  • Block quote: <blockquote>Block quote</blockquote>

About the Author

Daniel Koć

Since 1999 I play with Linux, since 2001 I'm an editor of polish news service LinuxNews, since 2004 I also work on polish Wikipedia, sometimes I translate from english (e.g. Jamendo - since 2006). I'm (more...)

New AdTaily ads!

Are you a film buff?

film buffs community, movie recommendations and reviews

RSS: Comments

You can follow the comments to this article through a special channel RSS 2.0 .

Related articles: Linux

 more »

PolishLinux Top Content


Become our fan on Facebook!

PolishLinux.org on Facebook

Follow PolishLinux on Twitter!

Follow polishlinux on Twitter

Google Ads