This is a read-only archive. Find the latest Linux articles, documentation, and answers at the new Linux.com!

Linux.com

Feature

New approaches to Linux package management

By Irfan Habib on November 10, 2005 (8:00:00 AM)

Share    Print    Comments   

Traditional Linux package management systems such as RPM, Debian's dpkg, and Slackware's pkgtool present several problems for users. Users who want optimized packages often have problems finding them, different package repositories have conflicting naming conventions, and binary packages are often not available for packages in a timely fashion. However, for users willing to stray from the beaten path, there are alternatives. Two projects have taken up the challenge of making a package management system that overcomes these shortcomings.

Linux is available for a number of architectures, which is one of its advantages. However, most packages are generally compiled only for i386, or i686 -- leaving users of alternative architectures with a dilemma. Users wanting packages optimized for other architectures often have to wait longer for pre-compiled packages, or resort to compiling the packages from source on their own, which defeats the purpose of using a package manager.

Availability of binary packages is also a problem for certain projects. I am an avid fan of KDE and a Slackware user. Every time a new version of KDE is released it takes a week or two until the Slackware packages are available, and the alternative, compiling KDE from source, with all its dependencies, can take an entire day.

Another problem with existing package management systems is that they contain scripts that automate the installation. However, if the scripts contain bugs, then users may need to employ complicated workarounds to rectify the problems. Even worse, if a package's installation script fails, it might be impossible to remove the package without extensive manual effort.

A new breed of distributed package management systems have emerged which make use of Internet-based repositories to give users the packages they require, customized for each user's architecture.

Gentoo Portage

The Portage package management system is a central feature of the Gentoo Linux distribution. Portage, which takes after the Ports system used with *BSD distributions, is a pioneer in the distributed package management paradigm for GNU/Linux distributions.

Portage uses the rsync protocol to update its tree. Updating all of the software in the entire distribution is as simple as entering the command:

emerge --sync

This command updates the local Portage tree with the current Portage tree for Gentoo. To update all of the packages on your system, run emerge -u world.

What about installing new software? To search for a specific package, simply run emerge --search packagename .

Portage can also handle dependencies automatically. To install a package, run:

emerge packagename

This emerge command tells Portage to download the source code of a specified application, as well as all other applications or libraries needed to satisfy its dependencies. Once downloaded, everything is compiled from source. You can optimize the compilation settings through the CFLAGS environment variable, based on the specifications of the individual computer, and on the individual user's need for speed.

One drawback of Portage is that it relies on the Gentoo Portage tree. If a package is not available in the tree, then a user cannot use Portage to install the package, and must resort to compilation by source.

Portage is one of the innovations that has enabled Gentoo to gain a large user-base very quickly, and it solves several of the problems found with traditional package managers.

The Conary Software Provisioning System

The Conary Software Provisioning System is developed by rPath, a company founded by ex-Red Hat engineers. Conary applies new ideas from distributed configuration management tools such as GNU arch and monotone.

According to the designers, "Conary uses networked repositories containing a structured version hierarchy of all the files and organized sets of files in a distribution."

Rather than concentrating on separate package files in the manner of traditional package managers, Conary relies on a tree-like structure that resembles to a software configuration control system. The Conary tree, unlike the Portage tree, can be distributed across a network. That is, a package compiled for i386 can be kept in the repository at rpath.com, and someone else might maintain the package for an alternate platform in another repository. The Conary tree can span multiple repositories, and hence potentially provide access to a vast array of packages.

Conary is able to utilize binaries if available, or source if necessary, and stores all version information in a database in order to track changes from the source branch all the way back to changes in the local versions installed on a given system to meet dependencies without conflicts. In some ways, Conary acts as a revision control system for package management.

Conary's command-line syntax is very APT-like, and the GUI front end is similar to Synaptic. Conary is designed for the layman, and hence it is easy to use. For example, here are some of the commands for popular operations with package managers:

The command conary q packagename shows whether a given package is installed.

The command conary rq packagename lists the newest available upgrade.

The command conary update packagename installs or updates the requested package.

The command conary erase packagename uninstalls the package.

Say I want to upgrade KDE on a Conary-based system. Running conary update KDE resolves all dependencies and updates all of the necessary packages for KDE.

Conary is an exciting tool for users who are frustrated with traditional package management systems. At least two distributions make use of Conary for package management: rPath, which was created by the designers of Conary, and Foresight Linux .

Conclusion

Conary and Portage were designed to address many of the limitations of traditional package manager. The Linux developer and user base has grown enormously over the past decade, and packaging systems have not kept pace. Many do not scale well to multiple repositories with conflicting or overlapping content, which can make it difficult for developers on different projects to coordinate package releases. Additionally, the increasing number of dependencies in many open source packages poses unique challenges to open source package managers.

One of the main aims of Conary is that it should be designed to enable a loosely coupled Internet-based collaborative approach to building Linux distributions that can change almost any aspect of a Linux system. With this kind of approach, Linux users might be able to manage their distributions with ease and not have to change their operating systems in order to circumvent the frustrations of a traditional package management system.

With the new breed of package managers users can now relegate responsibility for management of all aspects of software installation, upgrades, and removal to the package manager. With any luck, the days when users have to scour the Internet for optimized packages or missing dependencies will soon be over.

Share    Print    Comments   

Comments

on New approaches to Linux package management

Note: Comments are owned by the poster. We are not responsible for their content.

problems?! what problems?!?!?!

Posted by: Anonymous Coward on November 11, 2005 04:39 AM
I use Debian Sarge. No problems of any kind.*YOU* might have problems - I don't.

#

Re:problems?! what problems?!?!?!

Posted by: Stumbles on November 11, 2005 05:24 AM
Really. The packaging systems used by the distro of your choice works just fine. The problems I have had with packaging systems have been the following:

1. A repository was moved and I did not know of the change.

2. Packaging errors made by the person creating the dep, rpm whatever. This is the most common.

Those are the only two real instances ICR. Oh there may have been the odd occasion where there a bug in the program itself.

But none of those can be avoided no matter what management system you use. As for one universal no matter what distro you use packaging system, well, keep your dirty mitts off my sourced based distro.

#

Source-based is univeral, nothing else really is

Posted by: Anonymous Coward on November 11, 2005 06:30 AM
Universal packaging system: source archives and stow,xstow(extended, not x11), or one of the newer equivalents.

Example:

tar xzvf mypackage-3.1.tar.gz
cd mypackage-3.1.tar.gz<nobr> <wbr></nobr>./configure make
sudo make install --prefix=/usr/local/packages/mypackage-3.1
cd<nobr> <wbr></nobr>/usr/local/package
sudo xstow mypackage-3.1

and to uninstall something:
xstow -d mypackage-3.1
rm -rf<nobr> <wbr></nobr>/usr/local/packages/mypackage-3.1

Of course you don't have dependency tracking, etc, but I haven't yet seen any form of dependency tracking that was actually cross-distro and actually worked...

Of course, honestly, I haven't yet found a problem with Debian... I mostly use stow on my mac laptop to install debian-sourced packages (apt-get source and rsync are your friend) so that the scripts I use to manage stuff at my day job work whether I'm on one of the management servers or my laptop.

If you're on debian, of course, it's usually as easy to debianize a package as it is to use stow. software that uses standard configure script will usually debianize automatically, and the other kinds need manual handholding for debianizing AND stow.

Of course, keeping a few locally-debianized (rpmed, whatever) packages up to date is a lot easier than keeping an entire source-based distro up to date...

#

Re:Source-based is univeral, nothing else really i

Posted by: Anonymous Coward on November 11, 2005 04:34 PM
> Example:
>
> tar xzvf mypackage-3.1.tar.gz
> cd mypackage-3.1.tar.gz<nobr> <wbr></nobr>./configure make
> sudo make install
> --prefix=/usr/local/packages/mypackage-3.1
> cd<nobr> <wbr></nobr>/usr/local/package
> sudo xstow mypackage-3.1
>
> and to uninstall something:
> xstow -d mypackage-3.1
> rm -rf<nobr> <wbr></nobr>/usr/local/packages/mypackage-3.1

or:

$ sourceinstall mypackage-3.1.tar.gz

and to uninstall something:

$ sourceinstall --remove mypackage-3.1

#

Re:Source-based is univeral, nothing else really i

Posted by: Stumbles on November 11, 2005 08:55 PM
Well that's fine if you want everything to live in<nobr> <wbr></nobr>/usr/local. Except for a few, nearly every source tarball I've seen uses a default prefix of<nobr> <wbr></nobr>/usr/local. And I should qualify that by saying source tarballs from the original authors. Not ones that might have been massaged by whatever distro.



Not that there's anything wrong with that. IMO it's a decision that should be left up to distro maintainers.



So what a universal installer would have to account for is all the different places applications live, which can and are distro specific including binary and source disrtos.



And what if I wanted to use gcc-4.0.0 instead of 3.4.4 on a source based distro? What then? That one thing and deciding to use glibc with nptl instead of linuxthreads would be a monumental headache for a do all package maintainer.



It would also have to setup a build system for source bases distros. And the build system for Gentoo is not the same as used by Lunar-Linux, which it not the same as used by<nobr> <wbr></nobr>...... another.



It would be a huge monumental task. For what gain? Little that I can see. Not that I'm a distro, um, ahem lady of the evening. But I have used several and find all their package maintainers like urpmi, etc works as advertised. The only real difficulty I've had using them (ones I'm not familiar with) is finding the application name in the GUI menus and perhaps setting up additional repositories.



Right now the only real suggestion I would like to see across all distro and desktop managers is a consistency between menus. That IMO would be more useful.



None of those problems screams to me there should be one universal do all app. This suggestion to me sounds like an obtuse attempt or at least obfuscated attempt to create one distro.

#

Re:problems?! what problems?!?!?!

Posted by: Anonymous Coward on November 11, 2005 09:18 PM
Last night:

emerge amarok


      eventual message: can't find libstdc++.la

Just because it is a source based distribution, that doesn't remove the possibilitites of packaging errors. The<nobr> <wbr></nobr>.tgz raw sources sources are subject to errors in the included configure scripts. Source packaging is just as in need of bug reports as binary packages are.

#

Re:problems?! what problems?!?!?!

Posted by: Stumbles on November 11, 2005 09:48 PM
Well of course. Every package manger I've used source and binary based (not that I've used them all) occasionally has a dependency issue. None of that is the fault of the application but entirely due to human error. And a do all would have the same problems.

#

What about yum?

Posted by: Anonymous Coward on November 11, 2005 03:09 AM
I've been using <a href="http://linux.duke.edu/projects/yum/" title="duke.edu">yum</a duke.edu> for years, long before portage, yet there's not even a passing mention of it. Was the author in such a hurry to profess his love for emerge and Gentoo, and to express his issues with RPM-based systems, that he failed to make even a cursory search for a similar tool? What about apt?

#

Re:What about yum?

Posted by: Anonymous Coward on November 11, 2005 05:28 AM
The problem with yum is that it allows no access to repositories other than those on the web. A.K.A. no CD repositories. Users have to use a different interface on RH/Fedora to install from their base cds than they do from the web. And quite frankly, the CD install interface is awful and rough-handed. This is very inconvinient for non-highspeed or simply unconnected users. Not that gentoo handles this much better, but they atleast provide a package CD that can be used with emerge. I don't know about this new coronary system as I've never used it. Apt-get is what I use, because it provides easy access to both CD and web repositories. It would be nice to see a file format that could be used to install repositories like you would install packages, or maybe a meta-package format that could contain all the dependencies for a package tarballed into one (and corresponding programs to handle these). hmm i might just have to work on that.

#

Re:What about yum?

Posted by: Administrator on November 11, 2005 09:55 PM
"And quite frankly, the CD install interface is awful and rough-handed"

And mildly defective; If you run the auto-update, it very quickly breaks the ability of the CD installer to function. Dependancy errors make it useless, and can even break other general RPM installs and anything that ends up refering to the CD repositories for dependancies.

I'm kinda considering Redhat Enterprise Linux for my next distro, but not without research, because if EL has these sorts of issues, it's not worth a dime. I'm also considering Linspire, though not just for CNR.

(I'm looking at commercial distros cause I want brain-dead simple, out of the box support for several proprietary technologies. Mostly codec related. On a related note, does anyone know of an MPlayer based browser plugin?)

#

whoopsy, that's not right...

Posted by: Anonymous Coward on November 11, 2005 03:45 AM


If an ebuild (text file explaining portage how a package can be build) is not provided with the main tree, you can create one youself, ask or hire someone and put it in an overlay. Overlays are mini-trees you can maintain yourself, or even find on the net for some applications. This may seem complicated at first, but it's going to save you lot's off time in the long run...

So, tough possible, no need to short out portage and compile manualy.

#

Re:whoopsy, that's not right...

Posted by: Anonymous Coward on November 22, 2005 07:09 PM
BTW, ebuilds ARE pretty simple to use, especially for the few thing that are not in portage, which typically are little - rarely used - packages.
here is an example for a perl module I needed that wasn't in portage:

inherit perl-module

DESCRIPTION="Math::Random"
HOMEPAGE="http://wiki/twiki/bin/view/Labo/Ebuild"
SRC_URI="http://mymachine/mirror/${P}.tar.gz"

SLOT="0"
LICENSE="Artistic"
KEYWORDS="x86 amd64"
IUSE=""

SRC_TEST="do"

In many cases all I have to do is to copy an existing ebuild and change the description!

#

Sorry, but this article....

Posted by: Anonymous Coward on November 11, 2005 06:55 AM
...could have been a lot better:

You are not mentioning yum or smart, and you do not compare to them.

So why is portage better than apt or yum? Where does it has the features where the others are lacking?

And: just solving dependencies is nothing special, yum and smart can do this also.

Sorry, but your article looks just like an article from someone who does not know what he is talking about - but I have to admit that you haven't compared apt to rpm, that's one mistake several people do all the time and which shows that these people has no idea at all...

#

Re:Sorry, but this article....

Posted by: Anonymous Coward on November 11, 2005 09:49 AM
Exactly. This could have been a far wider review, not just plug. ie, apt supports building from source. In fact all packages are submitted to the archive as source, and they are then built by the compile farm. The source packages are often available LONG before the binaries, and they are often totally automatic to turn into binary packages, including turning on optimisations.

I only really know apt, but I would have loved to learn more about it's colleagues in the package managing world.

#

Re:Sorry, but this article....

Posted by: Anonymous Coward on November 20, 2005 01:30 AM

In fact all packages are submitted to the archive as source, and they are then built by the compile farm


That isn't entirely true for Debian. A package is uploaded both as a source archive, and as a binary package.



If the package applies to other architechtures then those will be built from the source. If not the uploaded binary is sufficient.


I believe that in Ubuntu all uploads are source only - but for Debian at least one binary package is uploaded to the repository.


So when I upload a new package, for example, I build it from source on my x86 machine and all other platforms get it built by the <a href="http://buildd.debian.org/" title="debian.org">Debian autobuilders</a debian.org> - but not on x86. The package end users get is the same as the one I built and uploaded.

#

Re:Sorry, but this article....

Posted by: Administrator on November 11, 2005 07:37 AM
Exactly... Where is smart in all this. It works great<nobr> <wbr></nobr>:)

#

I wish

Posted by: Anonymous Coward on November 11, 2005 08:34 AM
I wish that all linux dists has the same package management system kinda like all linux dists use bash and X.<nobr> <wbr></nobr>:)

Does it have binary signing?
Signed binaries?
md5/sha1? cryprographic hashes?

Microsoft has an<nobr> <wbr></nobr>.msi installer, it seems pretty cool.

#

Re:I wish

Posted by: Anonymous Coward on November 12, 2005 04:40 AM
Conary supports both signed binaries and sources

#

Re:I wish

Posted by: Anonymous Coward on November 12, 2005 04:43 AM
The Conary package management system has support for cryptographic package signatures. It's pretty cool, you should check it out.

#

Conary seems like god-sent

Posted by: Anonymous Coward on November 11, 2005 08:48 AM
I've been recently frustrated with RPM because it locked installation in the middle and I cudnt even uninstall the software.

Can u install portage in a non-gentoo based distribution?
I'll definitely try conary out if you can not use portage in non-gentoo based distributions

#

zeroinstall / 0install

Posted by: Anonymous Coward on November 11, 2005 10:39 AM
zeroinstall is the best bet of them all.

#

Re:zeroinstall / 0install

Posted by: Anonymous Coward on November 12, 2005 09:42 PM
In case anyone is looking for a link:

<a href="http://0install.net/" title="0install.net">http://0install.net/</a 0install.net>

There's also a comparison matrix here:

<a href="http://0install.net/matrix.html" title="0install.net">http://0install.net/matrix.html</a 0install.net>

#

Some Clarifications

Posted by: Anonymous Coward on November 11, 2005 11:41 AM
I am the author of the article, Let me address some contentions readers might have about the article:

I intentionally selected Portage and Conary, because they seem to have a significant following. Portage is the de-facto pioneer in distributed package management in Linux distros.
Sure, some package manager following the same paradigm predated portage, however they have not been adopted by many in the community. Yum for example has no major distribution backing it.
Conary on the other hand has distributions such as Foresight and rPAth which have been consistantly gaining ground.

About the ebuild thing, I thank the reader for pointing out a mistake in the article and filling a gap in my knowledge,
However this article was written with average desktop users in mind who would not go to such lengths as create their own ebuilds.
Irfan Habib

#

HowTo: GENTOO 2005.1 INSTALLATION SCRIPT/WALK-THRU

Posted by: Anonymous Coward on November 11, 2005 11:50 AM
HOWTO: GENTOO 2005.1 INSTALLATION SCRIPT/WALK-THROUGH
& JAVASCRIPT MOVIES.



Interested in a script to walk you through a Gentoo Linux installation? Then click here:


<a href="http://linux.coconia.net/" title="coconia.net">http://linux.coconia.net/</a coconia.net>


Even if you do not use the scripts the information on this page will make the installation much easier.


Links to the scripts can be found at the bottom of the page.


I would be interested in any errors that anyone may find.


There is also code for JAVASCRIPT MOVIES (and a couple to watch).

#

Re:Some Clarifications

Posted by: Anonymous Coward on November 11, 2005 01:53 PM
What??? No major distributions using yum? What about Fedora and Centos? They are as major as it gets.

#

Re:Some Clarifications

Posted by: Anonymous Coward on November 11, 2005 04:39 PM
Why do you write that Portage was the first system? It came along with Gentoo, or not? Gentoo was around 2002, and there even yast existed, which is able to solve dependencies and all the stuff. apt and yum existed there, too.

About yum: well, I would call Fedora, which is completly setting up on yum, a larger distribution. I dont't think that even Foresight and rPath together has a user base which is as big as the Fedora/Red Hat user base...
Others, like CentOS and Scientific Linux, which are derivatices of Red Hat Enterprise Linux, are using yum, too.

So: Although I see that, for example, yast, yum and urpmi are not able to build from source (what is not option for a averare computer user, by the way), I do not see the other advantages of these described tools.

Are they able to use mirror-lists like yum and smart? How can they work against the often called "dependency hell" which comes up when two developers start to submit the same package to different repositories?

Questions and questions...

#

Re:Some Clarifications

Posted by: Anonymous Coward on November 11, 2005 05:26 PM
A snip from the Conary web site

"Anyone responsible for system maintenance or system configuration wants to accomplish their tasks in the simplest and safest manner. Traditional packaging systems make loading a new release of an application or library easy, but do so in a "blanket" manner. When traditional systems update packages, they have no regard for determining whether the files being replaced are pristine or not. Changes are simply overwritten whether the file has been changed or not. Writing unchanged files over again creates greater overhead and is intrusive to a well-running system. The risk is normally small, but the overhead is significant.

Just as source code control systems use patch files to describe the differences between two versions of a file, Conary uses changesets to describe the differences between versions of components. These changesets include the actual changes in contents in existing files, the contents of new files, name changes (if files are renamed but otherwise unchanged, only the change in name is included), permissions changes, and so forth. They also can include changes to components as well as to individual files.

Conary changesets are quite often transient objects; they are created as part of an operation (such as fetching a new version from a repository) and disappear when that operation has completed. They can be stored in files, however, which allows them to be distributed like the package files produced by a classical package management system. Applying changesets rather than installing whole new versions of libraries and applications allows Conary to update only the parts of the system which have changed, rather than blindly reinstalling every file. Changesets are more efficient than classic packages in at least two ways: they take less space to express what changes to make on the system, and they take less time to apply the changes to the system when the set of changes required is small. These benefits apply whether the changesets are acquired through a network connection to a repository, on a CD, or via any other method.

Representing updates as changesets not only saves space and bandwidth, it also allows merging. Conary intelligently merges changes to file contents and file metadata such as permissions. This capability is very useful if you wish to maintain a branch of an application or library while keeping current with vendor maintenance, while adding a couple of patches to meet local needs.

Conary also preserves local changes in essentially the same way. When, for example, you add a few lines to a configuration file on an installed system, and then a new version of an application is released with changes to that configuration file, Conary can merge the two unless there is a direct conflict (unusual, but possible). If there is a conflict, it is marked as such so that modifications can be applied. Also, if you change something as simple as a file's permissions, those changes will be preserved across upgrades.

A local changeset is a special changeset that represents the changes made on a local system. There are two ways Conary allows you to commit local changesets: committing a local changeset to a repository, and distributing the changeset to individual systems. The first is better for systems with entirely centralized management policies, and the latter for individual systems that are expected to autonomously update themselves asynchronously.

Changesets represent a sane approach to preserving changes to a system while ensuring system integrity and limiting resources used to make such changes. System customization and maintenance are no longer an obstacle with Conary."

#

Re:Some Clarifications

Posted by: Anonymous Coward on November 11, 2005 09:25 PM
Sounds nice - so like delta-rpm system, which is used by suse.

You have the same idea behind it that you don't have to install everything new just for a few codeline updates, you jsut download a delta-rpm which will only update what's needed.

And the local changes are handled by rpm itself - if it comes with new configuration files it does not overwrite the oled one, but creates a failsafe of the new one (not sure in which cases of the new or of the old one).

So, it's a nice idea, but it's not something which is unique in the linux world...

But we are getting into an area where you can hardly blame an author for not knowing everything - there are only a few people who have the knowledge to compare all the package systems out there. But the author should be aware of this fact, too...
So it's not the best way to talk about "limited" package managers when I am not sure what these limitations are about...

#

HowTo: GENTOO 2005.1 INSTALLATION SCRIPT/WALK-THRU

Posted by: Anonymous Coward on November 11, 2005 12:02 PM
HOWTO: GENTOO 2005.1 INSTALLATION SCRIPT/WALK-THROUGH
& JAVASCRIPT MOVIES.



Interested in a script to walk you through a Gentoo Linux installation? Then click here:


<a href="http://linux.coconia.net/" title="coconia.net">http://linux.coconia.net/</a coconia.net>


Even if you do not use the scripts the information on this page will make the installation much easier.


Links to the scripts can be found at the bottom of the page.


I would be interested in any errors that anyone may find.


There is also code for JAVASCRIPT MOVIES (and a couple to watch).

#

Pacman/ABS

Posted by: Anonymous Coward on November 11, 2005 07:13 PM
This is Arch's package management system. It is sort of a hybrid way to both the approaches: ease of use/binaries and sources.

Pacman is the binary manager, and it works like conary/apt. It resolves all the deps and other fancy things, and it's really easy to use.

If you prefer source builds, there's ABS (the Arch Bukld System) that works just like portage: you update the tree and recompile the packages you want with only one command, makepkg. Your rebuilt packages perfectly integrate in your system, like emerged ones.

For more infos: <a href="http://archlinux.org/pacman/" title="archlinux.org">http://archlinux.org/pacman/</a archlinux.org>

#

Re:Pacman/ABS

Posted by: Anonymous Coward on November 12, 2005 01:57 PM
Agreed, pacman/ABS are the best package management tools by far.

#

Package distribution and transportation

Posted by: Anonymous Coward on November 11, 2005 08:22 PM
There is IMO a big miss understanding in what is package distribution and what is transporting packages. These are IMO two completely different things. Package distribution is delivering packages to a workstation in a way such that a package can be installed without any problems. This mostly means to take care for all the package dependences and solve them. It doesn't mean how they are transported, it's completely irrelevant if packages are delivered by rsync, http, or any p2p network.

O. Wyss

PS. See also "<a href="http://wyodesktop.sf.net/index.php?page=pkgdist.html" title="sf.net">http://wyodesktop.sf.net/index.php?page=pkgdist.<nobr>h<wbr></nobr> tml</a sf.net>"

#

Features and all are nice but...

Posted by: Anonymous Coward on November 12, 2005 01:03 AM
What I'd like as a user is a package installer / manager that could take whatever the software I wanted came in and merge it into a unified installed software and dependency tracker. As a developer, it would be nice to release 1 package and have it work for everybody. A TALL order, but if delivered a major leap forward to making linux accessable to users without expert admins.

#

Re:Features and all are nice but...

Posted by: Administrator on November 12, 2005 02:49 AM
Well, preparing the product to be distributed is part of being a developer.

A lot of open source projects just get released as unprepared source code, leaving users the deal with all the dependancies and often don't even go through an optimization stage, expecting everyone else to buy a new computer again.

Windows software has dependancies too, but they know what libraries come with the operating system, and include the ones that don't. They've solved this problem and it's a relatively simple system.

1) They know what's in the system.

2) They include what isn't.

This is seperate from most OSS projects, which goes like this;

1) They have no idea system it'll be run on or what's in it. There is no set of packages which can be expected to exist.

2)<nobr> <wbr></nobr>...There is no 2.

People think the LSB is supposed to solve #1, but it doesn't do a thing for that. Frankly, I'm not even sure what it's for or if anyone gives a damn what they're up to.

#

I disagree

Posted by: Anonymous Coward on November 12, 2005 04:00 AM
I don't think that the "traditional" package mangement tools provide "present several problems for users". They may do so for some freaks who want to waste their time on optimizing their system to maybe get 1% more performance out of it. Given the appropriate knowledge to do the tuning right, that is.

Most users are way better off without emerge, but with the traditional tools. Especially Debian and Ubuntu are fantastic for just about every user.

A typical user might not even install any new software but just stick with what he had installed in the first round.

#

Re:I disagree

Posted by: Anonymous Coward on April 15, 2006 06:33 AM

A typical user might not even install any new software but just stick with what he had installed in the first round.

A typical computer user uses Windows XP. Does that make it a good OS?!
Roumen.

#

Re:I disagree

Posted by: Administrator on November 12, 2005 04:11 AM
Umm, it's fairly broken on most systems wether they're specially optimized or not.

I find packages that fail to install on FC4 that are ~specially built~ for FC4.

Plus running the updator makes the whole package system break.

That said, typical users install programs all the time.

Most people like to, you know, actually do things with their computer, not just poke at it and try to make it run faster.

#

Portage on Slackware

Posted by: Anonymous Coward on November 12, 2005 09:22 AM
i've played with this to varying levels of success, but there's more to a distro than just the package manager, which is probably why slackware users like the author and myself stick to our favored OS. i've been attracted to portage, but haven't liked Gentoo on the whole.
Emerde is a port of Portage to Slackware, and even integrates with the native package manager. i'd strongly suggest installing ONLY the base packages before installing Emerde, because it's scripts for eyeing all previously installed packages aren't entirely up to speed, but otherwise it works.
check it out:
<a href="http://emerde.freaknet.org/" title="freaknet.org">http://emerde.freaknet.org/</a freaknet.org>

#

autopackage

Posted by: Anonymous Coward on November 12, 2005 04:41 PM
here's a wild idea... what about software that's not from a repository? being able to install non-crippled software that's not from 1998? try autopacakge, similar feel to a windows installer, but uses the unix permissions thing to its advantage.

have a gander:
autopackage.org

#

Portage overlays

Posted by: Anonymous Coward on November 12, 2005 07:49 PM
One drawback of Portage is that it relies on the Gentoo Portage tree. If a package is not available in the tree, then a user cannot use Portage to install the package, and must resort to compilation by source. This is not entirely true. Ebuilds are instructions to portage detailing how to handle a package and contain
variable definitions (including DEPENDencies) and maybe some overloaded functions.
If an ebuild exists it can be added to a portage overlay and from that point on it will be handled by emerge. It is also fairly easy to create ebuilds for simple packages. (KDE doesn't fall into this catagory though.)


One of the other great things about portage our the little helper apps like revdep-rebuild that searches for programs that are linked against other packages that may have been updated or removed. This tool will find and rebuild all of those programs/packages.


But the greatest thing about Gentoo is the fact that it is a live system. Nobody with a functional Gentoo install cares when a new version comes out. If they keep their systems upto date there is absolutely no reason to ever reinstall an updated version of Gentoo again. This does complicate some things like the recent Apache and MySQL updates but it is worth the occasional hassel for a system that is always current.


In response to other comments: It does have package signing for the sorce tar balls. Although you can't interact with Gentoo's remote tree other than to sync against it, once that is done the tree can then be shared with many other systems via nfs and emerge can even be coaxed into building binary packages for deployment on other sytems of like configuration. And to those that think there is a one-size-fits-all approach out there similiar to Microsoft's: sorry. GNU/Linux is a constantly evoloving system and as such many things are in a constant state of flux. To have a standard that developers could write to would involve having a code freeze for GNU/Linux/X/Gnome/KDE/E/etc... and a long shake out period. This is contrary to the way in which FOSS is developed. A program written against all of the newest libraries won't work until people get upgraded and if it is written to be compatible with older libraries it will be out of date upon release or shortly thereafter.


RiverRat

Gentoo.org and
irc://irc.Freenode.net #gentoo

#

Re:Portage overlays

Posted by: Anonymous Coward on April 15, 2006 06:27 AM
I used Slackware, Debian, Redhat/fedora and I must say the reason I decided to move to Gentoo for good was the fact that I could have:
1. A system that need never be re-installed but still runs the latest & the greatest
2. Flexible packaging system that allows me custom USE flags for every single one of my packages if I wanted, package dependency system that doesn't bog me down to the ground because some little silly package wanted some particular other package for no obvious reason but because the packaging database said so.
3. Slots. Gentoo allows me KDE 3.4 & KDE 3.5 on the same system! How cool is that?!

I hate enjoying my linux box just to find out that soon I need to wipe out everything because NextLinuxVersion x.xx.x has come out and my system doesn't have all the cool stuff the new one has.
I have a lot of custom scripts and all kinds of setups that run on my system and do different things. Reinstalling a new system is so much hassle to me that I will give anything to not do it. Fortunately with Gentoo I don't have to give up much. Just a little time in the beginning when all packages compile. As soon as the initial gentoo setup is complete gentoo maitenance is as much as any other Linux distro.
Gentoo has a few weaknesses:
1. Slow start time - it can take hours and even days to install Gentoo with all the blows and whistles on it compared to other distros where it could take as little as 30 mins. Last time I installed gentoo on my desktop I wanted some serious software like KDE & Gnome. KDE alone took me about 2-3 days to compile. Gnome is a little better. But you know what? I don't regret it because now that I have it all I do is run my updates at night and when I get up in the morning I wake up to a new KDE/Gnome/whatever. Last time I wanted to upgrade from KDE 3.4.1 to 3.5.2. and it took me about 2-3 days to install the new version but it all ran on a terminal while I was using all my old kde programs so I wasn't sitting there at the black screen waiting on gentoo to finish it all so I could use Kmail or Gimp. This is because Gentoo has something called SLOT's that will let you install more than one version of a software concurrently. I have yet to see a distro that has that.
Gentoo is not a system for the average programmer-joe that shows no interest in building a system that can last them for a long time and just likes to pop their cd in and have it all running in less than an hour. Gentoo is for people who like to poke around, research, spend time understanding how the system works. Gentoo is a distro for long-term use.
Roumen Semov - semovrs _at_ concord _dot edu

P.S. Some may wonder - how come Gentoo doesn't have OS versions like other standard linux distros. My answer is: because Gentoo is extremely flexible. Gentoo's versioning system is blurry or almost nonexistent because the packages installed do not define the OS nor vice versa, this is how flexible Gentoo is.

#

Re:What about yum?

Posted by: Anonymous Coward on November 13, 2005 11:36 AM
"I am kinda considering Redhat Enterprise Linux for my next distro, but not without research, because if EL has these sorts of issues, it's not worth a dime. I'm also considering Linspire, though not just for CNR.

Its basically superflous for EL since the system-config-packages is also updated and available from RHN for every major update and you can get media kits including those versions.

For future updates, you are relying on up2date anyway. EL is worth the dime you provide for the all the certifications (hardware and ISV), support etc and not for its package management capabilities which arent nothing bad either

#

Try smart

Posted by: Anonymous Coward on November 14, 2005 05:29 PM
Its basically superflous for EL since the system-config-packages is also updated and available from RHN

Many times we isntall software that we don't want to have to wait for, and its not always possible to use up2date during kickstart installs (especially on a network that might not have internet access).

We've set <a href="http://smartpm.org/" title="smartpm.org">smart</a smartpm.org> up for our network installation media for RedHat, and also for our custom software yum repo, and now only use RHN/up2date for updates (not for installing additional packages).

Smart supports all the major repo formats, including the hdlists on the RHEL media, and is present in a number of rpm-based distributions and Ubuntu.

#

Re:Portage

Posted by: Anonymous Coward on November 14, 2005 05:26 PM
after having used rpm based then debian based distros

The emerge --search tool in itself is worth the wait

Guess you missed apt-cache search, and haven't tried Mandriva (urpmq/urpmf).

So, I can't take this conclusion seriously:
I find Portage to be the best Package Management system I've used to date

#

Re:Portage

Posted by: Anonymous Coward on November 15, 2005 02:58 AM
"yum search" is available in fedora.

#

Dependancies

Posted by: Administrator on November 11, 2005 10:01 PM
Hypothetically, something as simple as RPM could work if we had more standards.

And I mean this is a very, very specific way;

First, a standard set of libraries and naming conventions for a desktop (other contexts would have different standard sets) would be defined.

Then distributions targeting the desktop (or other given standard set) would include those libraries as a minimum.

Software developers working with the standard would statically link dependancies not in said standard.

The standard would include things like GTK, QT, Gnome support, KDE support, SDL, etc. basically enough that unreasonable things wouldn't have to be statically linked.

But if, for example, a program requires an obscure library for panoramic image processing, something about one in a million Linux users are likely to need, it would be statically linked.

That would greatly simplify everything, and make it so you don't even need an automated dependancy downloader.<nobr> <wbr></nobr>...Opinions? Is such a thing worth developing? I think it would kinda solve the problem at it's source, instead of these glue-on-top bandaid solutions like apt, yum and cnr.

#

There's also Sorcery...

Posted by: Administrator on November 11, 2005 03:51 AM
Sorcery has branched into a few distros; Lunar, and Source Mage to name a couple. It's a pure bash (at least in Source Mage) package management system. Works off the original source tarballs.

<a href="http://www.sourcemage.org/" title="sourcemage.org">http://www.sourcemage.org/</a sourcemage.org>

#

Portage

Posted by: Administrator on November 11, 2005 10:04 AM
I must admit, after having used rpm based then debian based distros, I find Portage to be the best Package Management system I've used to date.

The emerge --search tool in itself is worth the wait whilst watching Gentoo compile!

#

This story has been archived. Comments can no longer be posted.



 
Tableless layout Validate XHTML 1.0 Strict Validate CSS Powered by Xaraya