Slashdot Mirror
Is RPM Doomed?
Ladislav Bodnar writes "This is an opinion piece offering solutions for all the ills of the RPM Package Manager. It has been written with Slashdot in mind - it is a fairly controversial topic and I would like to hear the experiences and views of other users who have tried different package formats and different Linux distributions. The conclusions are pretty straightforward - either the big RPM-based distributions get together and develop a common standard or we will migrate to distributions offering more sophisticated and trouble-free package management. Note: the main server allows a maximum of 100 simultaneous connections. To limit the /. effect, here are two other mirrors: mirror-us and mirror-hu (the second one has larger fonts). Thanks in advance for publishing the story."
So. The only contribution that redhat has ever made that was worthwhile to the linux community might be headed out the door.
What a legacy.
with Slashdot in mind. Isn't that normally called trolling?
For example: FreeBSD's ports kick RPM's ass!
Those of you who are in college now -- do you youngsters still use RPN on HP calculators?
I hate it! You need to compile a new RPM for each platform
.tar.bz2 package which dectects what OS your using, and compiles and installs automagicly with a easy to use gui and a powerful cli interface
What we need is a smart
It is now official - Netcraft has confirmed: *RPM is dying blah blah blah
I don't have problems with RPMs at all. I use apt-get since it was first introduced in Conectiva Linux, and I'm now using it in a Red Hat box. I upgraded it from 7.2 to 7.3, and the only problem I had was lack of space in /var to download the files (not my fault, but from the former sysadmin).
From the page...
"This article is currently under preparation. Please do not post links to it and do not submit it to any new sites. Thank you."
---- Booth was a patriot ----
I think the biggest thing we need with rpm (and other distro systems) is standardized package locations. That would help, *extremely*.... as well versioning control needs to be better. For example, I hate having to have 2-10 different versions of libraries due to programs requesting their own version, even though the newer libraries could do the job of the old ones. As well, when the rpm asks for another rpm which is not installed, but the libraries are on your machine (in the right location) it is frustrating.
I hate to say it, but maybe we need a standardized "registry" idea like in MS Windows? I hate to say it, but they do have a good idea with that.
===> An eye for an eye makes everyone blind - MG
various alternatives to RPM packaging? I don't know much about this, but I've found QNX's Package Installer to be quite efficient and trouble-free (at least in 6.1, can't say much on the new one in 6.2NC) compared to what many experience with RPMs..
Then again, RPMs would work better if more distributions were a little more uniform in their cores (UnitedLinux might solve this?)
Who cares?
The Solaris pkg method is tight, easy to do and proven. Linux could definately use this. Die RPM Die.
Gentoo Linux uses a system called "portage" which will download, compile, and install programs from source (binary for some packages). It is fantastic. Similar to apt it will check for dependencies and get those also. But the use of source is what turns me on. I'm converting all my linux boxen to it. Even inspired me to slice up the disk on my Win2000 box and go dual-boot.
"More organs means more human." - Zim
If the other links are overloaded, you can read the story on my site. Maybe other mirrors should be posted in this thread.
Teenagers these days don't have as much sex as they want each other to think they do.
No depency checking, but it also means that you don't have the problem of circular dependecies and the like. Plus you can open it with tar and gzip. Linux Packages is a great place to look for pre-built Slack packages.
I used to use RPM, but now that I've converted to Slack, I don't miss it one bit.
"Backups are for wimps. Real men upload their data to an FTP site and have everyone else mirror it." -- Linus Torvalds
I administer a few RedHat servers, mostly 6.2, and 7.2 which each perform a different function. If an RPM is offered for a piece of software I need to install, I usually download that first.
If the rpm install fails, I will spend about 3 minutes troubleshooting the issue. If I can't get it to go, I download the source and compile from scratch. 9 times out of 10 this works without having to figure out dependancies.
RPM works great when the envirnment is exactly the same as the build envirnment. When it's not...well, it just plain sucks. Source almost always works without incident.
Really, there is nothing to difficult about:
./configure
make
su
make install
Although it only works for products where the source is openly available.
RedHat needs a compile from source package format that most people can figure out. srpms may do it, but I have no clue how to use them.
-Pete
Soccer Goal Plans
Not all mirrors have this notice. So the mirror you visited needs an update.
Teenagers these days don't have as much sex as they want each other to think they do.
I fully appreciate the author's sympathies. I'm used to replacing RPM-based distros; just last night I burned a new Mandrake Cooker so I could try it. KDE3.01 et al are just too hard to get right using RPM upgrades. But then he mentions gentoo...
/etc (etc.!) files.
...which I have also tried to install. Trouble is, gentoo has *no* installer, past the kernel stage. I can't even get sound to work, becuase my mobo sound chip isn't in their ALSA tree. I'm sure there's a way to do it but they don't tell you. Gentoo users are typically, I suppose, the type of Unix experts who have no trouble figuring out which driver goes where. But gentoo lays things out differently from RedHat (etc.) so I can't just copy their
If gentoo had a decent installer, not necessarily as "friendly" as Mandrake (more flexibility is a plus) but which could guide all the files into the right places, then it might be a killer. For now, it's a cult for experts. But I don't see why a binary-based (or at least partially binary-based) distro couldn't use an apt-get or portage-like system when needed, without requiring gentoo's exceptional knowledge (well, that's what it feels like to the "n00b" whose recent Linux experience is mostly RH and Mdk) of the distro's layout.
I hate tennis.
From the article...
> On the other hand, have you noticed how hard it is to find Debian ISO images?
http://www.linuxiso.org - I can't believe you've never heard of this place. They've had Debian ISOs since I first learned of them.
I admit, debian.org's ISO download wizard is garbage, but I think they're trying to save bandwidth by having you download what you need instead of the entire ISO (there's no reason you need to install every package in the ISO).
niko
I use Debian Unstable at home because I always want the latest and greatest software and I already know how to fix 95% of the apt/deb problems that occasionally happen. At work, I use Debian Stable because I never want to touch the server after it's been configured and tweaked.
The good thing about RedHat and Mandrake to some extent is that they do good testing on the RPMS on the cds. I figure they don't expect people to install some 3rd party RPM off the net.
"I keep looking in the want-ads under 'revolutionary' but there don't seem to be any listings.. "
The author mentions, "On the other hand, have you noticed how hard it is to find Debian ISO images?" Yes, Debian is very upgradable, but that has nothing to do with the percieved shortcomings of the RPM package format.
The RPM format is nearly identical feature-for-feature with Debian's dpkg. RPM's upgradability has nothing to do with technical issues. There are three things that make Debian's package management so much better than RPM-based distributions.
The first is, there are way more distributions based on RPM packages than deb's. It's not suprising that some of them are more incompatible with each other than any debian release has ever been. Sure, there are many more people with hairy backs in the US than there are in Lichtenstein, that doesn't mean that living in the US causes hair to grow on your back. He is inferring causality where it doesn't exist.
Second, APT. APT is what makes debian's package management so smart, not dpkg. And, in fact, this isn't a reason at all. APT now works with RPM packages, and when dependencies are properly configured, it is every bit as good as it is on debian. You can make an APT repository with RedHat's "rawhide" distribution and upgrade daily if you want. You won't have any more upgrade issues than you would running debian unstable. It may break occasionally, but it's when large changes happen. The exact same thing happens on the debian side.
Third, Debian is fanatical about consistency. Most debian packagers manage maybe three or four packages (there are exceptions, of course). When you devote all of your free time to just a few things like that, a lot of attention is payed to details. This is what truly makes Debian's package management so freakin' clean. It has nothing to do with technology, it has everything to do with each maintainer hand-crafting dependencies and build options very carefully.
The thing that pretty much any of the RPM-based distributions is truly missing is the equivalent of the Debian package maintainer guidelines, and a culture that enforces it. If that existed, RedHat would be just as consistent and upgradable as debian.
I use RedHat and I'm careful about what I put on my system, and I never run into upgrade issues. If I'm going to install something that is for a distribution other than mine, I build from .src.rpm's instead of binaries and I *know* it's compatible with my install. Someday, if packagers stop being idiots and using shortcuts, I won't have to. Everything will resolve properly in the huge worldwide-apt-rpm-uber-archive.
WWJD? JWRTFM!!!
My jaw dropped as I read this. I've been running Mandrake for over a year now and have been getting SICK of trying to upgrade/install software. What has really intrigued me has been Gentoo. Just last night I was reading through the Gentoo install instructions again thinking: "Wow, do I really want to risk trying to do this on my main (currently dual boot) machine?" Was this just intuition on the part of the author? I find that hard to believe.
You have to ask yourself - where are these users coming from? Gentoo is not easy to install, even with the excellent instructions provided you still need to be pretty familiar with Kernel internals to get all your hardware work. You need to make decisions whether to enable Unix98 PTY support and magic SysRq key, get familiar with Grub and load the correct module for your network card. Surely, a daunting task if your entire previous computing experience was gained from using Windows! Mandrake makes all those tricky decisions for you, Gentoo does not. No, all these new Gentoo users are not users abandoning Windows. They are users who have been around Linux for some time, many of them still have visible bumps on their foreheads. They are ex-Mandrake users, trust me on this one.
I hate it! You need to compile a new RPM for each platform
.tar.gz2 package which detects what OS your using, and compiles and installs automagically with an easy to use gui and a powerful cli interface
/i ce -20 rpm -tb "$@" && rpm -Uvh `find $our_rpm_buildroot -type f` && rm -f `find $our_rpm_buildroot -type f`
:-)
What we needis a smart
Well, hell.
------
#!/bin/sh
# Demonstration that RPM ain't all that bad
# Copyright 2002, 0x0d0a
# This code placed under the GPL
# Should compute proper buildroot, etc
# Be damn sure not to set buildroot to
# or something similar -- rm -rf would
# then suck severely
# Set our_rpm_buildroot appropriately
# Usage: mybuildrpm.sh foo.tar.bz2
our_rpm_buildroot=/usr/src/redhat
n
-----
Okay, I grant that there's no gui, but you get all the many CLI options of RPM. Voila!
People love to bash RPM, but it's a pretty sweet system (except the move to the newer underlying dbfile...screw transactions, I can always rebuild the database if it gets corrupted and it takes *much* longer to install and query than things did back with rpm 3.0). If it's too simple for you, it's really easy to use it as a back end and slap something on top of it.
Note: this is a one minute hack and may not even run, much less be safe for your system...it's an example, not intended to be used. And hell, running random stuff from people on Slashdot as root just isn't a great idea.
May we never see th
The registry in Windows creates a single point of failure. The point of the registry seems to be copy protection. The registry contains incomprehensible data. It is an area meant to be outside the user's control.
I really hope that plain old source tarballs will stay, I've noticed with recent releases of several software packages, the rpm was released _before_ the plain source, or even only the rpm. It scares me, I really don't want to be forced to use rpms for my system (slackware/linux from scratch). You loose a lot of freedom, deciding what/where/...
I don't understand why people have to offer tarballs, rpm's, deb's, slp's,
Take a look at Ximian's ftp server. For every new version, they have to build specific packages for every distribution, and even every different version of that distribution.
People like me who either like to build from source, or don't have one of those 'supported distributions' - like my slackware and lfs - can't install ximian. Or have to go through hell and back to trick the crap out of the installation-scripts.
I don't want to start a flamewar, but this is not 'free software', if you need specific systems and/or packagers to install it. If it only supports commercial systems like redhat/suse/..., and not me with my little self-made linux system that I made just because of the philosophy gpl-given liberty and the fun of doing it, than it doesn't follow the philosophy I see behind the gpl - or only partially.
The first time I installed an RPM which was not included on the CDs, I was wondering badly what happened.
Where was the program?
It was not in the K menu.
It was not on the desktop.
It was lost.
So I thought something went wrong and installed the RPM once more but it claimed the rpm was already installed.
I eventually realized it was indeed installed but the installer did not:
- ask me whether to put an entry in the menu
- decided for itself where the files were supposed to be
Never mind that I wanted the files to be in my home directory.
Never mind that I had no clue what the primary program name was.
There were dozens and dozens of other files in the RPM, mind you. It is not easy to determine what is a binary and what is not when you have just installed Linux for the first time.
And this does not even touch the subject of dependency hell. I have wanted to install several programs only to give up because of a huge number of dependencies.
There's been quite a discussion on the installer issue in the Gentoo forums (the thread can be found here). The general consesus from the users seems to be that they like Gentoo being kind of a "niche" distro. If the idea of the source based distro really appeals to you, I would suggest giving it another go and leaning very heavily on the forums (if you need to). Gentoo's Forums have the most helpful and friendly user base I have ever seen on the internet. I have yet to see a single person give a n00b a hard time (outside of the occasional rtfm...). I realize that it's not for everyone and that it takes a little bit of work, but I think Gentoo is definitely worth it after the dust settles. It's nice to install an OS and feel like you actually accomplished something.
Oh yeah, and I don't like RPMs.
Many of you will have remembered that the RPM Package Manager went from 3.x to 4.x without backward compatibility and upgrading it was an arduous task, to put it mildly.
Aw, it ain't that bad. I found myself changing version numbers in RPMs with a hex editor.
Strangely, it actually worked just fine.
Sometimes I think they break backward compatiblity just for the heck of it.
While I agree with the thrust of the article, it would be much more persuasive with a little more meat behind it.
"There is at least one distribution (ESware) that has moved from RPMs do DEBs, but I don't know of any movement in the opposite direction."
A little research into just how many distros have migrated one way or the other in, say, the last five years would be instructive.
"Similarly, there are many users who have moved from RPMs to DEBs, but very few who have chosen the opposite path."
This statement is pivotal to the article, but is completely unsupported by any hard numbers, and comes off overly broad. (Surely there must be have been SOME attempts to determine market share of the major distros?) Maybe you don't know anyone who's gone the other way, but I'm sure it happens.
That said, there's a lotta truth in this article. After a couple years of struggling with RPM Hell on Red Hat and later Mandrake & Yellow Dog, I've recently decided to switch over to FreeBSD (ports, yum!) on my server and Debian on the workstation.
Oh, as an aside, there's an implementation of deb/apt for Mac OS X and Darwin, called fink. Fink supports both binaries with apt-get/dselect, and source installs with their own ports-like tool. I know a number of people who run traditional Linux/Unix progs, including X Windows, The Gimp, KDE, etc., side-by-side with their regular Mac apps. Oh so very cool.
Learn from the mistakes of others. You won't live long enough to make them all yourself.
Does the Apt-Get and the BSD Ports crowd have anything better to do than keep posting these BS articles? PEOPLE WHO USE RPM-BASED DISTROS DON'T GIVE A DAMN WHAT YOU THINK. GET OVER IT.
For linuxes the various source-based approaches are becoming more popular / solid. In addition to Gentoo, there are Sorcerer Linux and two working forks (Lunar and Source Mage) see summary.
As pointed out in a comment above this one, when RPM snafus (often) you can usually build from source with minimal effort. Unfortunatley that's not true for RPM itself, which I have found to be a major pita to build from sources, or things like Gnome / E17.
Vendor unixes (Solaris, AIX, HPUX) put a lot of effort into correctly managing dependency checking. Part of their solution, however is in building their own versions of sources and staying as much as 2-3 years behind the current-releases of any given package.
RPM is a far cry from the vendor unix approaches, part of which I'm sure is that it's trying to do a much harder task on a less well defined base platform (random hardware).
Try building RPM from redhat's sources sometime, use the force you're gonna need it! That alone suggests to me that this is not in 'reality' an opensource project. A GPL license for software that doesn't build with './configure; make' doesn't seem like an effective oss project to me.
Linux is Linux, if One need clarify their dist: <Dist>/GNU Linux
bsds are of course just BSD
My advice would be to the morons who don't like it to come up with their own packaging and see if it gets adopted.
I've had no problem with the RPM package with SuSE, Mandrake or RedHat.
Most problems with RPM are situated between the chair and the computer of the Linux user or the linux developper.
The article is obviously written by someone who dislikes RedHat for some reason or another and needs to get a life.
If Debian was so wonderfull more people would be using it.
The fact that RedHat or similar distributions are more popular should be a clue to the idiots who bitch about it.
Unlike winblows the argument of forced use will not work since none of these distributions are forced down anyone's throat.
Spreading the hatred against RedHat ain't going to make any of us switch to Debian or Slackware. Slackware may be good but it is no good when compared to fancy distributions like SuSE or Mandrake.
I do have Slackware on my computer but only use it to test some stuff. I find SuSE much nicer to use for most of my work in Linux.
Compiling it from source is almost never different from just grabbing a binary package and installing it. If it wasn't already compiled with the appropriate GCC optimizations, chances are compiling in those optimizations now will just lead to random instability. It's just an excuse for dorks in their basement with more time than brains to feel good about their l337 lunix b0x3n.
"I don't know that atheists should be considered citizens, nor should they be considered patriots." - George Bush
Debian.
Look A basic install, though perhaps not quite as bare as gentoo, is really bare. Really light.
You end up, with a minimal configuration, with teh bare minimum you need to boot, get a console, and install more packages over the network.
Then it's a matter of adding packages as you see fit... which is entirely too easy.
to get here, just skip the package selection and/or task selection (where you choose either individual packages, or in beginner mode, what kind of machine it's going to be, development, server, etc.)
I do every debian machine for every reason this way. I love it especially becaues it leaves me with a light, clean system every time.
One of the reasons behind Gentoo is probably one of the reasons why people used to love Slackware (heh, I guess some still do). Because you had to do things the old fashioned way. Get source, comipile, install where you saw fit. You had to actually learn how things work.
I can say that, in having ot mess with early, early version of linux I learned more about how unix works than any other unix I've used. Having to actually figure out, either by reading, or trial and error, what file goes a LONG way towards being able to work multi-platform.
Packaging is only the symptom. The problem begins with the design of the system layout or lack thereof (i.e the mimic factor is in place...), the systems Linux ... etc... etc.. are not designed to be installed, upgraded, patched, maintained. These things occured later in the development life cycle. This behavior is the norm in commerical products too
... the best workaround ... the question that really should be asked is 'how can we design a operating system that is installable, upgradeable, patchable' ...
Packaging is mostly a workaround... so what people are looking for is
I aggree,
I installed mandrake 8.2 a while ago, since then there have been a lot of 1.0 releases out.
OpenOffice,
Mozilla,
KDE (3.0.1)
etc....
But mandrakes packages have some rediculios deps, to install KDE 3.0.1 from there cooker(dev), it wanted me to update thinkgs like unixODBC and MYSQl,I don't wan't mySQL and call me stupid but obdc's a protocol!!! and i dont think the latest unixODBC changes that , why the hell have they put such non-granular pagkages togeter, if i had a release plan like that at work I'd probably be out of a job.
The RPM tree locations in mandrake used to be different from the package defaults which ment i could'nt install wines RPM and know i wasn't going to screw up package management some time in the future.
Dependencies of RPM's really need sorting out, and there should be no reason why i can install a suse package on redhat (so long as they both follow LSB!!)
grrrrrrrrrrrrrrrr
thank God the internet isn't a human right.
in itself. The problem is not using the hierarchal file system in a coherent way. In addition to that problem we have way too many files nowadays. When package contents mix with one another.. well I'm sure you've had Chem. 101.
This article wants solutions, so here is mine:
Make packages a seperate directory. Just like good old DOS days--where every program lived by itself in a directory. _All_ package contents go in this special directory. Then you have the problem of per-user configuration. This is incredibly simple. Have a directory in each user's directory which _mirrors_ the package directory. Each package directory should be unique (i.e. MyProgram v1.0 lives in a different directory than MyProgram v1.1). Dependencies would be much easier this way since you would only depend on a _directory_ existing. Moving packages would simply be a matter of packing up the directory and taking it wherever.
In any case, software is _package_ based. Why do we still throw library files from different packages together in the same directory?! When you want to remove a package you have to rely on broken package managers, or hunt down every file which goes with a package. We should be able to completely remove software by simply removing a directory. I've heard MacOS does this, why can't Linux?
Dijkstra Considered Dead
What we need is to get rid of the entire packaging system all together. I know I'll probably get toasted for this. But software should install in linux the same way it installs in windows. There should be one file, like setup.exe. I should take that file, execute it, it will ask me what parts of the software I want, and where I want to put it, etc. From my experience there are two pieces of software for linux that do this, the Tribes 2 server, and Mozilla.
The entire packaging system is just a pain in the butt. This depends on that depends on this. urpmi, rpm -i, rpm -U, things not working with no explanation. In Windows I never have to worry about one thign relying on another thing. Because just about everything uses DirectX. And directX COMES WITH anything that uses it. And it has a simple graphical isntallation.
There should be one downloadable file for each piece of software I want. It should install on its own, on any linux machine, easily and graphically. And all of my library packages like glibc, etc. Should transparently update themselves to the newest versions all the time. I dont' want to have to worry about that stuff. Drivers in linux are incredibly difficult to install. They should become a simple right click, install driver. Done. I want all that other crap taken care of for me. I don't have time to change paths in config files, tinker with code, look up crazy commands and recompile crap.
I feel the package system is the real place in which linux fails. Most distros, lets use Mandrake as an example, have graphical easy installations. But when you get to the package selection phase you're stuck forever weeding through thousands and thousands of checkboxes. Not cool.
One piece of software should be one checkbox. KDE alone has like 20+ rpm files. There should be one file. KDE3setup.exe.
You know that installshield that almsot every piece of windows software has? Maybe someone could code that for linux. I would, but I have no idea how to do something like that. But I know someone reading this does. And if you want to save your open source os, I suggest you do.
The GeekNights podcast is going strong. Listen!
RPM by itself isn't the real problem here. The author is complaining that installing applications in Linux is a pain in the ass, because the system often doesn't have all of the required libs installed.
I admit, RPM doesn't make this an easy problem to solve. Any normal Windows app would simply package the required libraries with it. Thus if the lib doesn't exist, it can install it. But RPM doesn't work that way. RPMs can only hold one logical unit. So one app, or one library, or one set of platform independent support files. RPM builders could include more, but doing so will likely break the RPM dependancy tree.
The real problem in all of this is the destinction between applications and the system itself. Is grep part of the OS, or is it an addon app? How do you tell? Most would argue that grep is a part of the OS, but you can easily install linux without grep, so it must not be essential. But if packages expect it to be there, then it must be essential. But if it's not part of the OS, then they shouldn't have expected it to be there in the first place, so now it is their fault for not thinking ahead... This problem just goes in circles all day. The worst part about this is that my use of grep is just an example. This problem applies to literally all packages outside of the kernel itself. Don't believe me? How about init? Do you think that init is essential? I agree, but what version? Do you want a SysV init, or a BSD style init? Technically you can have either.
To solve this whole problem, we really need to take two steps. First we need to define a base Linux system. And I don't mean a completely solid, unwavering, definition either. Standards that never evolve are quickly dubbed 'legacy'. The trick is to define a complete base install. Everything from the kernel, to the version of GCC (and no RedHat, gcc 2.96 isn't going to cut it), to what version of X is installed, to what "expected unix utilities" are available, and what libraries are available. Feel free to change the standard, but each time you do so you must raise the bar somehow, either by making it more reliable, or faster, or adding features, or some combination of the above. There is only one last key item to making this system work. You must retain backwards binary compatability for long periods of time. Feel free to completely break legacy systems, but make sure that you only do so after you've had at least 5 to 6 years of stability.
Then there is the second step. RPM is a nice system management system, but it is a shitty application packager. Mostly because of the dependancy issues and the fact that each RPM package can only hold one logical unit. We really need an install shield like system for applications (both gui and console installs in the same package). Feel free to keep track of what is installed, and what files belong to who, but you really need to separate the system from the applications. Once you have a base defined, keeping the system and apps under the same packaging system no longer makes sense. The absolute need for it is removed.
Come to #gentoo on irc.openprojects.net sometime....
ugh...its newbie land
It seems to me that most people that don't like RPM have either not used an RPM-based system recently or simply do not have the proper knowledge on how to use it.
It takes a while to learn to master rpm, yes, but that doesn't mean it sucks. If you don't know how to use RPM, stick to up2date.
I manage quite a few RedHat boxen using only up2date and rpm. It's true that there are sometimes unmet dependencies, but most of the time that is not a problem. If there's a problem it's almost always solvable by checking out http://rpmfind.net
Circular dependencies? What's the problem? Install both (or how many you need) packages at the same time (rpm -Uvh pkg1.rpm pkg2.rpm)
Piece of cake!
Still don't like RPM? Well, apt-get is available for RedHat too, check out http://freshrpms.net/
I like RPM. Ignore the FUD.
The problem with ANY packaging system is overzelous dependancy definitions.
.debs not because of any inherent superiority of .deb, but rather because of the hard work of the Debian maintainers to make sure the packages are all set up correctly!
When Maynard builds his SuperFlyFloobyDust.rpm file, rather than specifying the dependancies as "I need libPease.so", he accepts the default "I need libPease.1.4.2.thursday.5-31-41.1-pl3-build6.so". So, even though any libPease.so would work, you get a dependancy failure.
This is a failing not of any specific package manager - ALL package managers have this problem. You don't see it with
Additionally, there is the problem of library makers not following the fscking standards - libNarf.1.1.so is SUPPOSED to be fully compatible with libNarf.1.0.so - if it isn't, then it should be libNarf.2.0.so! However, you get people making libraries that don't follow this rule, so as a result you have to have libNarf.1.[0-99].so in your system because of programs that depend upon their version of that library.
The solution to this CANNOT reside within the package manager - it resides in the distribution maintainer to refuse to deal with packages that break the rules.
However, all it takes is one person installing one program that breaks the rules, and that installation is screwed.
That is where distros like Debian and the *BSD's have the advantage - they are controlled by folks who won't let that happen. However, how many people install from the unstable branches, and why? Because that's where the latest, greatest, shiniest stuff is!
www.eFax.com are spammers
Is *MUCH* better, thank you very much!
"Whenever the cause of the people is entrusted to professors, it is lost." ~ V.I. Lenin
Thanks "micheal"... you might as well post an "article" called "Is Emacs doomed?" or "Is Debian doomed?"
The author raises some good points and it's not that the discussion shouldn't take place, but the way in which the author has written the article is highly biased and obviously just troll fodder; he's not asking for opinions, he just wants you to read his.
"I hope to get this article on Slashdot or NewsForge..."
He then makes inflamatory statements like "Ask any Debian user and he will shake his head in disbelief that you, as a Mandrake user, have to download 2GB of software every 6 months and then run a risky upgrade just to get your system up-to-date. Silly you!" and " This is the main reason why we have seen so many new Gentoo/Sorcerer users, finally free from the RPM madness!"
Once again, we find the Slashdot editors lacking in any journalistic integrity and asleep at the wheel... and they want us to pay for their incompetence?!
It boggles the mind...
Debian's advantage lies not in the packaging format. Technically there's not much difference between rpm and dpkg.
What makes Debian stand out is the Debian Policy, which all Debian Developers must adhere to. Theoretically someone can apply that Policy to an RPM-based system, and it'll be as stable as Debian.
It's just as st000p1d as the DLL crap with Windoze. You might have an excuse with proprietary software that's kit-bashed from different sources or of which you may want to update or patch a "feature", but with software of which you have the source, there is NO EXCUSE for that dependency crap.
At least, that's one thing most Macintrash programs have right: no goddam fucking library/DLL dependencies. Everything is in one binary file!
With the big disks we have nowadays and the high bandwidth, there is no reason why you should not be able to include the whole fucking shebang with the application, and keep it isolated (to prevent it from breaking other programs) on your system while you compile it.
Having 50 (only that many) different styles of configuration files definitely makes things tough. However, the information is not hidden from the user, as it is in Windows.
It would be great if someone standardized Linux configuration files. I suggest a browseable, book-like or PDF-like interface like that in Ganymede. Each package would be expected to write their own interface to the configurator. That way, authors could have any configuration file format they wanted, but there would also be a standard GUI interface.
When I first tried linux oh so many years ago, I tried THE distrobution (from what I knew) called RedHat. I quickly learned to dispise RPMs, although for a n00b like me they were better than source.
I soon tried Caldera and a few others, I liked RH better, I don't remember why.
Then one day I tried Mandrake. In my oppionion this is a GREAT distro. In fact, it's the one I would use today if it wasn't for RPM. No matter how nice a distro it is, I couldn't stand fiddling with RPMs, downloading everthing I could find and still having it not work.
So I went to another famous distro: Slack. I liked slack alot, especially not having to fiddle with RPMs. Their packages had no dependencies, but they weren't RPMs. I used this distro for a few months, and it was nice, but I wasn't satisfied.
So out of sheer desperation, I tried the ultimate distro, Debian. I had heard it was tough to install. While it was no RedHat or Mandrake, by now I knew quite a bit about Linux and it didn't give me any problems. But what won me over was (like I assume was for so many others) apt-get. You just can't be typing "apt-get install gimp" to get the gimp. All dependencies resolved, all problems taken care of.
Now it's true that Potato (aka Stable) is out of date. It's stable as hell, but I don't think any desktop user should use it (servers are another story, as is often the case). "Testing" has been just as stable for me as full releases of Mandrake and others, that is no crashes. I've never used unstable, but hey, I've got a extra box lying around here somewhere.
So in short all my distro hunting can be put in a few simple steps:
This is purely my oppionion blah blah blah....
Comment forecast: Bits of genius surrounded by a sea of mediocrity.
Amen to that.
"Fighting terrorists with millitary might is like killing a mosquitor on your Dad's forehead with a rifle."
It seems that the countless hours of using Debian has morphhed this guy into an idiot.
Was this an critical look at RPM or a Debian LoveFest?
All bark, no bite. He whines about problems but offers up nothing to back them up, except of course, "Oh, Debian is a Wonderful distribution!"
rpm -i
Sorry, you need libpng x.y.z_e, but you have libpng x.y.z_c.
Above is not of course technically accurate, but many MANY times I end up annoyed with RPMs since theyre put in a requirement for a SPECIFIC named package and version (on the builders system) version of something. You can end up needlessly having to upgrade libraries when you already had an entirely adequate version for the package in question.
Solaris package management works. It can't really help us here though, since Solaris installations are generally very generic things - linux machines can be any one of thousands of combinations of package versions. Back to linux-land, and apt-get with debian mostly works, but a few times I've seen a debian machine decide to upgrade more or less the entire base dist for a trivial tool due to versions, and break in the process while replacing libc. Not fun.
The only workable solution I've seen thus far, is the freebsd ports system. Grabs the generic source and builds it in such a way that it only upgrades backup tools and libraries when it really needs to. I've NEVER had a serious issue in years of using this system. That's not to say it's perfect of course, still suffers the issue of you not being able to easily revert to your old setup if an installation breaks somethings, and of course it can be pretty slow.
Something does need to be done though. A Windows using friend of mine tried to install Mandrake recently, which he did all on his own without issues. He wanted an IRC client, I recommended x-chat. We tried using RPM and it failed, so we grabbed the source and then had to go about installing a set of development tools on his machine. It took a *long* time before the gcc package would install due to some idiot deciding headers should be split from main packages for the sake of a few kb of diskspace. Even then x-chat wouldnt build, due to things like the gettext rpm not having msgfmt (part of gettext), someone having decided it lived in an openwin tools rpm, which would no doubt have wanted lots of openwin rubbish installing. Eventually we ended up splatting source versions of common tools on top of the rpm installed ones to resolve several instances of missing header files and scripts. Finally, x-chat built...
It made *my* head hurt let alone his - and I've been working with *nix machines for years. It almost put him off trying to use linux any further straight away. Linux is never going to start making any non-techie inroads unless someone sorts out a decent packaging system, and fast.
--
ALL YOUR BASE ARE BELONG TO US!
I started my Linux experience with SLS and a 0.99 kernel. Then I switched to Slackware, then flirted with Caldera. Then for a while I ran RedHat on my servers, before switching in about 1999 to Mandrake on all machines.
And then I decided to experiment with Debian on a test box, and fell in love. I now have it on my desktop, my laptop, and three out of my five servers.
Why?
The package manager. It just works. It just works reliably, installing all the right stuff, resolving all the dependencies. When there are conflicts (not often) it reports them and suggests remedies. In short, the Debian package manager is to all other UN*X package systems I've ever seen as a computer is to a tally-stick. No-one who has used dselect will ever go back to RPM.
I'm old enough to remember when discussions on Slashdot were well informed.
I've been using UP2DATE to update my Red Hat installs, and never have had any problems. Unless you all are busy installing crappy free games that aren't supported well and not doing any real work on your computers, I can't imagine any Red Hat Linux user having any problems with RPMs.
You got the OS for free, that's good enough. Now start paying for your games and junk and you'll get good quality RPMs. Unless you want to play with stuff some 14 yr old made before homeroom, in which case you'd better expect some problems.
Sheesh!
Let us for a moment pretend that instead of using .debs (but still had APT, ala Connectiva), Debian used RPM for its package management. Would Debian be as good as it is now? Of course. Why is this? Well, because the Debian people spend a hell of a lot of time making sure the package management is done properly. This has drawbacks of course, like the lack of the latest-and-greatest software (notably XFree86 4.2 and KDE 3), but in terms of stability you really can't argue that Debian is the best around.
The author then goes on to suggest that a Gentoo-like system is whats best. Quite frankly this just shows us more about how little the author understands what is necessary in a package management system. Don't get me wrong, I like Gentoo a lot (in fact I type this message on a machine running Gentoo :)) but package management really isn't its strong point, as things like the recent libpng problems show. Doing things this way makes dependencies extremely difficult to deal with. Lets pretend you have libxyz installed, and then install program abc. abc can use libxyz, but doesn't require it. As you have libxyz installed, gentoo compiles abc with libxyz support enabled (one of Gentoo's best features). However, the day after, you decide to 'emerge unmerge libxyz' (remove libxyz for Gentoo virigins). abc no longer works properly. Gentoo didn't tell you that abc needed libxyz, because it's not a dependecy.
In my opinion, the package format is irrelevant; RPM, DEB, TGZ, all are fine as long as they are centrally controlled and well put together. A system like APT makes things many, many times better, becuase it eases dependency problems, but it isn't a pre-requisite.
Blaming GW Bush for the Iraq war is like blaming Ronald McDonald for the poor quality of food.
Say your package directory was /usr/app (or whatever, there are standards for these things, y'know)
libpng would live in /usr/app/libpng, qt would live in /usr/app/qt. Things could still dynamically link them, and it would still Just Work. The only difference is that you don't have four hundred files all crammed in /usr/lib.
"Break out the gin, and the small violin, I'm a raging success as a failure." --Firewater
I've found it easy enough to compile from source when there's no RPM or I need to set lots of parameters (i.e., PHP).
But what about uninstalling? Is there a command I'm unaware of to remove software compiled and installed from source? It's easy with RPM.
Ladies and gentlemen, I hate to be the one to inform you, but this isn't RPM's fault, this is the individual distro vendors' faults for not standardizing on a filesystem hierarchy.
I also blame the users who don't have enough sense to build thier own rpms. It's not *that* hard, if you have a SRPM, to build an RPM that works on your system where the binary may have failed. In fact, I recommend that if you use RPMs that don't come from your distribution vendor, you get the source RPM, edit the spec file as appropriate, and build your own...this way you're linking against *your* version of whatever libraries you have installed. It's not *that* hard, trust me.
-Jeff
Really, there is nothing to difficult about:
. cgi?attack_linux+attack/%{name}-%{version}.tar.gz
/sbin/ldconfig
/sbin/ldconfig
/usr, but after you do this, note the names of these files in the package and specify them individually
./configure
make
make install
And all RPM does is automate and standardize this process. The strength of any management system is based around its ubiquity. Installing software outside the packaging system is a bad idea, as suddenly all those standard installation, uninstallation, querying, and verifying systems no longer work - for your unpackages apps, and all the broken packages or other unpackaged apps that rely upon it. Stop thinking of RPM as being seperate from source. it isn't. An RPM is a cpio archive with a source tarball and a spec file like the one below which automates the build process.
Summary: An addictive and frantically paced puzzle game with cute 3D graphics
Name: crack-attack
Version: 1.1.7
Release: 2mm
Source0: http://aluminumangel.org/cgi-bin/download_counter
License: GPL
Group: Amusements/Games
URL: http://qcd2.mps.ohio-state.edu/attack/
Packager: Mike MacCana
BuildRoot: %{_builddir}/%{name}-%{version}
BuildRequires: glut-devel
Requires: glut
%description
Crack-attack is addictive and frantically paced puzzle game with cute 3D graphics, playable either against the computer in single player or across a network mnultiplayer, where o
ne players success clearing blocks dumps large immuntable tiles upon the others block pit. Muahahahaha!
%prep
%setup -q
%build
%configure
make
%install
%makeinstall
%post -p
%postun -p
%clean
rm -rf %{buildroot}
%files
%defattr(-,root,root)
/usr
This will catch all the files installed in
%doc AUTHORS COPYING INSTALL NEWS README
%changelog
* Thu Apr 11 2002 Mike MacCana 1mm
- Created packages
Now I'm going to sit back down on my Red Hat 7.3 box and apt-get dist-upgrade all my RPMs from Freshrpms.net
First of all, building from source makes things a lot easier. Gentoo/ports style package databases should be the future.. the compatibility is much better. Still, if you manually upgrade something (without the package), the package manager is still clueless that you have installed a new version.
So, what can we do? For instance, a few weeks ago when I was trying out Gentoo, I got the BitchX package and installed it. Unfortunately, the latest version was old and still had a number of bugs. The solution is very simple, have something monitor the files as you install! Imagine something like INSTALL_CMD="make install" emerge --manual --version 3.2.1 BitchX And emerge would monitor file changes, new files, and then update the package database. Obviously the details recorded for this wouldn't be as great as from a manual package, and the package might even be compiled with the wrong options. Still, it's definately an improvement. Comments/ideas?
The trouble with standardised config files is that this relies on all linux apps or processes interacting with the user or administrator in the same way. In other words, someone has to come up with a format that is "all things to all people" which is not concordant with the Linux "ethic" (for want of a better expression). Most Linux users want "infinite" latitude for customisation.
The BSD ports and packages work pretty well.
/usr/ports/comm/kermit
cd
make
It downloads, compiles, and installs.
Got a package file? add_pkg package. The article didn't make any mention of these possibilities.
When I download a source tarball, I can look in the README or INSTALL file, and find out what things it needs. RPMs have no such facility. Add to that, who *knows* what command line options were used, if some features were left out, etc.
I'll stick with source, thank you.
ttyl
Farrell
CAN-CON 2019 - Ottawa's only book oriented Science Fiction Convention! October 18-20, Sheraton Hotel, Ottawa, Canada h
You do realize that you can do a minimal installation of RH and install as you see fit? Just like Debian? The main difference is that you actually have industrywide support for your distro.
May we never see th
Let's see:
1. An RPM-based distribution is risky to upgrade
Not quite. Red Hat, for example, still supports upgrading from Red Hat Linux 4.x to current versions, if you use the official updating process.
You can run into problems if you upgraded some stuff by yourself, which is true for any package manager. A good package manager doesn't downgrade packages during an upgrade process. How is it supposed to handle an "upgrade" from a custom kdebase 3.0.1 installation (compiled with libc 5.x) to the kdebase 3.0.0 package found in the distribution you're trying to update to?
Downgrade things in the process? I think that would make people complain, as well.
Similarily, apt-get works quite nicely for Conectiva users.
2. A more complex binary RPM package is often hard, if not impossible, to install
Again, this is not exactly specific to RPM. The problem here is that RPM is used much more widely than any other package manager, therefore RPM packages are typically built on a wider range of potentionally VERY different systems than other packages.
If, say, 200 distributions used
3. The incompatibilities between different versions of the RPM Package Manager added another layer of complexity.
This is true, and the only real rpm specific problem.
There's always a tradeoff between new features and backwards compatibility, and rpm does seem to lean a bit too much towards new features.
4. The developers are forced to consider differences between distributions and create multiple binary packages.
This is just restating point 2, and is just as invalid.
Same for the suggested "solutions":
1. Learn to build your own RPMs
This actually does fix some problems... But of course you can't expect everyone to do it.
(See also #5)
2. Petition the RPM distributions to adhere to common standards.
Nice in theory, but because there's no real standard ATM, this would mean breaking compatibility with older versions of the distributions (by e.g. adapting a common scheme for naming packages so you won't need to make a difference between Red Hat'ish "Requires: kdelibs >= 3.0.0" and Mandrake'ish "Requires: kdelibs3"), possibly breaking the update path.
3. Use more advanced package management tools, such as urpmi or apt-rpm
I agree with this one (add up2date to the list, btw). The availability of those tools shows that rpm is actually a good and flexible package manager - it just needs some extra tools to simplify some common tasks. It's really the Unix way of doing things - have the tool do one job, and have it doing that one job (handling individual packages without resolving dependencies by itself, in the case of rpm) well. Then write other tools making use of the tool (rpm) to get more advanced functionality.
4. Switch to Debian or Slackware
As shown above, their package managers do not solve the problems mentioned in the article. The problems just happen not to show up so frequently because there aren't many distributions using these package management systems, and the ones that do are usually pretty close to the distribution they're based on. Much closer than completely different distributions like e.g. Red Hat and SuSE, which really don't have much in common except for the package manager.
If, say, Red Hat switched to using
So this switch wouldn't gain anything.
5. Switch to source-based Linux distributions, such as Gentoo or Sorcerer
This does solve the problem, but introduces others. It's a good thing for some people, but certainly isn't a universal solution to all problems.
Source based distributions are really nice for people who want to tweak things a lot, but they aren't very useful for a traditional desktop user (who typically doesn't have all that much of a clue and doesn't want to spend a lot of time learning), and they introduce problems even for users who can handle them.
Let's assume you have a source based package manager that is dumbed down enough to allow a user to install a package by clicking on a package file in Konqueror or Nautilus.
Here's some of the problems you'd still need to solve (and some of them really aren't fixable):
This is a real problem on slower machines - Compiling, for example, OpenOffice takes approximately 13 hours on an Athlon 1800 with 1.5 GB RAM. Imagine installing it from source on a Pentium with 128 MB RAM...)
foo.cc:123: invalid conversion from `const void*' to `void*' is supposed to mean? (It's typically an indication of broken code that happened to work with gcc 2.x, but doesn't work with gcc 3.x anymore - but how does a newbie know or fix it?)
Besides, rpm is powerful enough to provide this functionality for people who want it, combining the best of both worlds - it's typically as easy as
rpm --rebuild foo-1.0-1.src.rpm
rpm -ivh
This still has the same problems as a pure source based distribution, but with rpm, you get the choice between building from source and installing the binary.
It's the primary reasons why I prefer rpms over debs, by the way - they're much easier to build.
This message is provided under the terms outlined at http://www.bero.org/terms.html
I agree. Apt4rpm is great.I have it pointed to the 7.3 repositories, but would like to use RawGide. But I can't seem to point it to RedHat RawHide. Can you tell me where the repository is?
A simple packaging system based on tarballs, a la Slackware
Try administering a network.
My experience with Slackware is seeing people managing to *just* get their system working and then leaving chunks of the software along and letting it get ancient because they don't want to break anything. They upgrade a library, they end up with zillions of broken library dependencies and programs that won't run.
May we never see th
Maybe I'm missing something here, but are you really saying that a binary compiled and packaged by someone else may be less secure (or maintainable) than code you've built yourself? That doesn't make sense to me.
I was very anti-RPM a few years back - even as late as RH7.0. I still compiled all software from .tar.gz source and installed appropriately. If I couldn't get the source to compile for some reason (strange dependencies that I could not track down), I'd end up trying a rpm -Uvh --nodeps foo.i386.rpm. Without the --nodeps, the installation would fail 99% of the time - the files it needed were there, but not in the RPM database. /usr/src/redhat/SPECS/foo.spec. All you have to do is d/l the .src.rpm file, install it (usually installs 2 files /usr/src/redhat/[SPECS/foo.spec | SOURCES/foo.tar.gz]). You can tweak the .spec file (the ./configure line is in there - modify to your hearts content!), then do the -bb command listed above. /usr/src/redhat/RPMS/i386/foo.i386.rpm. Have a lot of like-OS machines (I have 7 RH7.3 machines at home)? Compile your binary RPM on the fastest machine (a dual P-III 850 VALinux box here), install the binaries on each machine. /usr/share/doc/rpm*, and make the call then.
Then, for some reason that escapes me now, I tried a pure rpm-only box. Dependencies were still a pain the the ass to some extent, but much easier with sites like rpmfind - just type in the missing dependency and d/l the topmost result for your architecture, and voila - the original package installs fine.
I missed being able to compile from source, though. The security aspect is one major plus, but being able to tweak PHP to include EXIF, TrueType, and libGD support so my web apps keep working was the clincher.
Enter rpm -bb --clean
Grab a coke, come back, new package file specific to your installation is in
This ability combined with the most EXCELLENT red-carpet and up2date capabilities in ximian and RH, respectively, make RPM usable for the masses. I have seen many low-end-tekkies (no disrespect, of course) using red-carpet on their personal machines with no hiccups. Need do remove something to get this new software? OK - it tells you. Need extra dependencies for the new package? OK - it's all automatic. (They don't even need to know that RPM and red-carpet are crypto-checking the stuff they install to ensure there's no man-in-the-middle work going on!)
RPM is really powerful. There's a LOT more than the features I've listed here. Want to see what files have changed since you installed the XFree86 RPMs? rpm -V XFree86. It tells you if the date, file size, contents (MD5 hash), and a bunch of other stuff have changed or if files are missing since install. It even tells you if the file is a configuration file, meaning a change in size, date, and content is not necessarily something to be concerned about.
Please don't think my support of RPM is blind - I have used Slack, played with Debian, and done the 100% source code route. RPM is a great tool, and most linux users (even some of the very skilled ones) don't use it to it's fullest potential. Spend a day or two reading the man page, the files in
Full disclosure - I am an RHCE, but I was sold on the advanced stuff RPM can do way before I took the class and test. Check it out - you might be surprised at what you've been missing. Feel free to e-mail me after unmangling the addy if you like...
You would need to make an APT repository for it (in the same way the apt4rpm guys made redhat 7.x repositories).
I have my own, but it's not for public use... I don't have that kind of bandwidth. =)
WWJD? JWRTFM!!!
This article is rather coincidental to me as I posted something about upgrading Mandrake yesterday: Usenet post. I want to upgrade a Mandrake installation, but I don't want to 1) burn any CDs; 2) download MBs of data that I'm never going to use.
As for Debian packages, is it the package management applications that work, or the process (i.e. the hard-work, care and attention to detail of the people who create and manage the packages)?
Sticking feathers up your butt does not make you a chicken - Tyler Durden
RPM itself is freeware.
Bitching about freeware is in very poor taste. People can bitch about the way Microsoft does things because they can't do anything about it. However, people have no moral right to bitch about any freeware; they have the source code - they can fix the problems themselves.
Doubtless some people will say: "But I don't have the skill"; to which I can only reply: Boo Hoo.
You forfeit the moral right to bitch because you have chosen not to do the work to fix the problem.
Fixing software problems is not easy for anyone.
Grow up. Quit trying to manipulate people who are willing to do the work. Join in yourself. Get your hands dirty, and see how much you enjoy listening to slackers bitching about your work.
My real GNU/Linux experience began with Slackware. It was nice and minimal. The packages (although hard to find) were nice and easy to manage. The rc.d files were easy to manage. It was nice.
/usr/local. The problem was that many stupid/inexperienced developers don't include a 'make uninstall' in their packages. Darn! Also, the general inconsistency of the GNU/Linux world (no central source) got me down, and so I switched to NetBSD. FreeBSD looked to bloated, and didn't focus on stability and good code. OpenBSD seemed to be just a copy of NetBSD. NetBSD focuses on stability, protability, and good code. These are the roots of security. The NetBSD packages system is really nice. I can build the packages from source (I don't like binaries), and it automatically builds dependancies. Also, it is very neat and tidy. No bloat whatsoever. I haven't tried to upgrade it yet, but will when NetBSD 1.6 comes out.
Then I got a new computer and installed Debian. The packaging system, which at first appeared nice, was nasty. I tried to upgrade my gcc from a package, it failed, and thereafter, all the gcc related packages were listed as 'broken'.
Then, after getting tired of messing with Debian, I did LFS (linuxfromscratch.org). It was quite nice, because I had complete control of my system. It was minimal. It had exactly what I needed, and no more. Packages were built from source, and installed in
Oh yeah, the registry is great, I can edit it with regedit remot... I can edit it with regedit!
What was that registry key called? Damn, can't remember... Ok, I'll find it. How many keys are there anyway? 1,000,000!?! Holy fucking shit man! It's a good thing that'll be easier to find than a file in /etc on Linux... Fuck! That's not true!
Plain and simple, the registy = single point of failure, and is not meant to be a feature for the user.
Sticking feathers up your butt does not make you a chicken - Tyler Durden
Ok, I'll admit that the optimizations get me all hot under the collar with probably no real performance increase.
But, that's not best thing about Gentoo and other compiled from source distributions. Let me give you an example:
I was trying to install SuSE on a server, I wanted a pretty minimal system. One of the things I needed on there was ssh. However, the ssh rpm had been compiled with X support, so of course I had to install X and various other X odds and ends. There were other silly dependencies that I can't remember aswell, things requiring QT/Gtk when they work perfectly well as console applications etc.
But dependencies are a major weakness of RPM or other package based systems.
If I were to try and do the same thing on Gentoo, it'd see that I wasn't installing X, and wouldn't compile X support into ssh. If at a later date, I wanted to install X, I could get it to add X support to any software that supported it very easily.
RPMs were the one thing that I never got along with in Linux. Currently I'm running an LFS system (mainly because I wanted to learn how everything works), but my next system will be a Gentoo system.
--
Hollywood representatives have publicly stated that skipping commercials is "stealing."
1) Red Hat and Mandrake were/are not excluded from UnitedLinux. All Linux companies are welcome to join. They may not have been in on the initial UL chats, but had they been included I wouldn't be even slightly surprised if at least Red Hat would have caused the talks to go nowhere with their "we're the standard, be like us" mentality. Leaving the Red Hats of the world out of the round #1 discussions was probably the only way UL got as far as they did.
/usr/ports/[directory name]" then "make install" is all it takes. System updates? "cd /usr/src", then "make world" (assuming all sources are on the system, which is VERY easy to make happen).
2) You oversimplify the issues of divergent Linux distros. If you think the main reason people leave distros like Mandrake is because of packaging issues, you're not looking at the big picture. I've tried just about all of the major Linux distros at any particular time (including SLS, TAMU, MCC, etc. from the days of the original Linux distros) and the only reason I have migrated from one to the other was because of operational issues and/or stability, not package management. The latter could have influenced my decision to move on, but it was never the majority reason.
3) You ignore the other direction people are going in (such as myself): *BSD. You toot your horn about Gentoo without acknowledging what Gentoo itself acknowledges: its package management system is based heavily on *BSD's "ports" system. Besides being sick of being told I can't use Linux unless I subscribe to the Linux religion, I find that the *BSDs (although not really compatible with each other) are simple to use, no more difficult to set up than your average mid-level-techie Linux distro, and I can get almost all of the same software running on it as I can on Linux. A simple "cd
I'd love it if people could weigh in with some comments on how to use RPM in a secure manner. I often (well, usually in fact) end up installing things as root, and occasionally this scares the hell out of me, when I stop to think about it. If the package isn't what it says it is, who knows what it could be doing . . .
This strikes me as a major danger of RPM, though not one that's the fault of the system -- it's the fault of users like me, who find RPM convenient without necessarily knowing what we should do to achieve both convenience and security.
What do security-conscious people do about this? I know we can verify authenticity of packages -- is taking that step sufficient? I don't want to relocate everything to install in my home directory -- I back up those files separately, and I don't when gigs of intalled applications sitting in there. I suppose I could create install directories accessible to humble-user-dave . . . Comments welcomed.
Unfortunately, installing that missing library fails because of three other missing libraries and two other libraries that come in incorrect versions. Depending on how badly you want the original package, you have two choices - either go and search for all missing dependent libraries as well as all libraries dependent on the dependent libraries, or you just give up. How many times have you given up?
Source rpms, duh.
-- Note: If you don't agree with me, don't bother replying. I won't read it.
Which is it? Even a quick glance at the article would tell you enough to make your post look silly.
.rpms isnt supported on THEIR system
.deb out there as there are .rpm
.deb its a standard. And standards are standards because people use them - and like them. Its not .rpm that should change, maybe its .deb.
I see nothing wrong about RPM compared to other systems
Dependency issues, RPM version problems etc. Read the article.
I can see why people running say Debian whine about RPM because
RPM is a Linux application, it runs on any distro. Alien integrates RPMs to the Debian system.
and I dont see as many
You're probably not looking in the right place. There are nearly 4,000 packages in the official Debian archive and many more maintained unofficially.
So either way if rpm is worse or better than
By that logic, we might as well all be running Windows.
It has been my experience that those who complain about RPM's rarely haave any idea what can be down with them, if done properly. For example, Pete's problem can usually be solved by grabbing the SRPM and doing RPM --rebuild xxx.src.rpm.
Sure, not a lot of people know how to make really good SPEC files, and therefore really flexible packages, but that's not a limitation of the technology. Just of the developers.
"In any case, software is _package_ based. Why do we still throw library files from different packages together in the same directory?!"
Um, well, cos that's the *idea*. Libraries are shared code, intended to be used by multiple programs/apps/packages.
"We should be able to completely remove software by simply removing a directory. I've heard MacOS does this, why can't Linux?"
That's the ideal on the mac, you're right. But in practice, it's seldom that easy.
On really old versions of the Mac, it was even simpler: an app was a single file that could be placed anywhere. All resources were built-in. Nothing was installed in the System directories, cos there wasn't one! Deleting an app meant dragging the one icon to the trash.
Just as the Mac OS got bigger, more sophisticated and more modular, necessitating it's own private directory, so did applications. They needed preference files, plug-ins, other optional components, etc., which generally went into the same directory as the application; so now applications had their own directories. Some large developers (Micro$oft, Adobe, Claris) tried to share common code and resources between their own apps, and generally put it in the new-fangled System Folder. Others built apps that depended on system extensions (think kernel modules), which likewise were installed into the System Folder amongst (and sometimes conflicting with) the Apple-supplied stuff.
By the time Mac OS 9 came out, things were outta hand. OS 8 (or 7, it's been a while) even introduced an Application Support folder in the System Folder, but developers generally ignored it. System stability was hard to acheive. Some suites, like MS Office, installed so many components in so many places that it was nearly impossible to uninstall, and nearly impossible to troubleshoot if something went wrong. It was getting as bad as Windows; many Mac power users simply clean-reinstalled their systems every six months or so. Whee.
Then came Steve Jobs. And Steve begat Mac OS X...
Mac OS X, as you probably know, is based on BSD (although with a Mach kernel). it's not straight-up BSD, though; there's no ports collection. Also, some directories have been moved and/or hidden from users. It does, however, have packages, and it's own proprietary package manager.
Actually, it has two types of package. One is the app package; like the Mac applications of old, this encapsulates the executable code and other resources into what appears to the user as a single file. (Actually, it's a directory, but the UI hides this from the user.) Installing these is trivially easy: drag and drop (or cp if you're into that). Not just for small utilities and the like, even MS Office installs this way. They can reside anywhere in the directory tree, within reason. Uninstallation is as easy as deleting the package file.
The other package type is the installer package; this uses a version of the NeXT installer to do dependency checking (rather badly, at this point) and handles the job of installing components into the right directories (system, library, user, etc). In general, it's only used for apps that require installation of system components.
In addition, many apps use their own installers, either becauuse of the deficiencies of Apple's installer, or just because they've Always Done It That Way (e.g. Adobe).
Ah, but then there's shared code and resources.
Like *nix, Mac OS X has shared libraries. Apple designed a sophisticated set of libraries, collections, frameworks and other system resources for all apps to use. These are, of course, hidden from the user. Since Apple designed the whole system, they also get to define the environment, so their system is more organized compared to the hodgepodge of libraries you see under *nix (although those *nix libraries are there too, if the user installs the optional BSD Subsystem and Developer Tools).
Fo sharing application resources, there's still the Application Support directory, and developers are actually using it these days. App code is kept very much separate from system code. IMHO it's a big improvement over *nix that way.
Learn from the mistakes of others. You won't live long enough to make them all yourself.
If a security problem is found in a function that would be found in libc, it is a hell of a lot easier to upgrade libc than to upgrade every single piece of software on your system.
- Broken (un)install/upgrade or configuration scripts.
- The requirement of and old package, that has since been upgraded (with the new package being incompatible).
- The requirement of a package, which files are already provided by a different package.
Oh, and pray there are no namespace clashes. This wouldn't be a problem if third-party apps were installed inAn ideal package management system would have no install/uninstall/upgrade scripts.
Files should be copied and a number of update programs should be run (such as ldconfig) and that should be it. No per-package scripts would be involved. This would reduce the package maintainer's work too.
There should also be no configuration scripts (like in Debian) too. Other packages containing configuration tools should exist instead, these packages would have a configuration relation that is queryable from a package server.
This problem exist soley because binary compatibility isn't taken seriously. If a new version of a program or library breaks binary compatibility or an API (command line options in case of a program), then it should be possible to install these different versions in parallel.
If two packages want to install the same file, let them. Assume it won't break binary compatibility because that's evil anyway (see 2). A timestamp (based on CVS checkin for example) for each file in the package would solve the problem of having the old version of a file installed.
An additional advantage of this would be that you could ship monolithic RPMs that contained all required files. No more dependency hunting!
An easy solution to avoid installing all those dependencies is to not install the dev packages unless you plan on actually writing kde apps which probably 99% of the people who install the dev packages don't want to.
This is a great idea:
/usr, /opt/kde, /opt/kde2 or god knows where. For packaging everyone decided to make a new name for the directory between /usr/src and /RPMS, you've got 'redhat', 'OpenLinux', 'RPM', 'rpm', 'packages' and those are just the ones I've noticed myself. We are getting to the point that we are seriously considering not supporting distributions that don't support the LSB. I've been very encouraged by SuSE's work in this direction, and disappointed at how bad Red Hat and Mandrake are."
"Depending on your distribution you've got KDE in
You'd think all the distros could get together and agree on LSB, or at least something. It really is needed, and needed right now.
-- Note: If you don't agree with me, don't bother replying. I won't read it.
The biggest problem I found with RedHat's packaging is that they don't do versioning properly. For example, I was trying to install GNOME a while back on an RH6.2 machine, and it needed [library] (I forget exactly which library it was) version x, but some other package on the system needed [library] version y. This meant that I couldn't install the prepackaged version of GNOME, and had to build it myself. This is just like DLL hell in Windows.
On the other hand, in Debian, if you have two versions of a library, and their API's are incompatible (which is the only reason packages would need to depend on a specific version of a library), you will have one package called, say, [library]1 and one package called [library]2, and packages can just depend on [library]1 instead of [library] version x. This way you can have both versions installed at the same time, and everyone's happy.
My second pet peeve with RPM is that you need to be root to build an RPM from source. In Debian, you just need to use "fakeroot", which means that the build process thinks you're root, but you can't accidentally do anything too nasty too your setup.
To get something done, a committee should consist of no more than three persons, two of them absent.
I'm glad someone is pointing this out. I'm sick of debianistas and slackware/gentoo (tarballs r00l!) clowns getting it mixed up. RPM is not at fault (though there are obviously things that can improve it)... the packagers are at fault. High-quality packagers are the key.
Summary
.deb for any given app is going to depend on every library that app can conceivably be linked against, regardless of whether you intend to use that function. This is what led me to start compiling stuff from source. And what happens when you get an app that requirse a library version higher than what Debian currently offers? You either have to wait, or install that library from source yourself. Excep that breaks hundreds of dependencies! Joy! The Debian way is not for everyone, and Debian fanboys are seriously deluded as to the relative merit of their system.
/usr/bin/install, that logs the files installed when you run make install. It's extremely handy for managing the apps you install from source. Unfortunately development was discontinued some time ago, not that it lacked any features or had any bugs, but it may be unavailable.
1. An RPM-based distribution is risky to upgrade.
The author has a strange conception of how often "risky" distro upgrades are necessary. I've been using Turbolinux, and RPM distro, through versions 3.6, 4.x, 6.x, and 7.x. For each major revision, I've fresh-installed my box. But between major revisions, I can just d/l the rpms from the update directory and install them, no worries. Is the process for upgrading from RH X.1 to X.2 so different, so much more complicated?
2. A more complex binary RPM package is often hard, if not impossible to install.
The simple solution is, don't install 3rd-party binary RPMs. In fact, don't install 3rd-party binaries period, unless that's your only option. Any software that's too big of a pain to compile from source (like XFree) is going to be on your distro CD.
3. The incompatibilities between different versions of the RPM Package Manager added another layer of complexity.
Solved by above solution to #2. Half the problems the author has with RPM are caused entirely by the use of 3rd-party packages.
4. The developers are forced to consider differences between distributions and create multiple binary packages.
This depends on what kind of software we're talking about. If it's and end-user app, and the developers want new users to be able to install it, then yes, they probably have to work out multiple versions for each distro. But it seems they'd have to do that anyway what with different library versions and file locations in each distro. The fact that you can't issue a single binary tarball (term used generically) for all distros exists apart from any problems with RPM, it is a systematic problem with all distros.
The author also seems to think Debian is a magic bullet. I quit using Debian right as apt-get was being introduced. At that point, the distro swelled beyond a single CD, which at the time was a horrendous amount of crap to come in-the-box. I also didn't have broadband. However, though hard drives have sinced passed 100GB and I have cable, I still don't like the "Debian way". I'm one of those people that wants something physical, even if I'll only use it once. It's not a big deal to download new versions nightly and just archive the packages on disk, but if that disk goes then I'll have to get my entire distribution over again, instead of being able to install from physical media. But questions of update method aside, the author also ignores the horrendous problems with Debian package dependencies. Debian packages have, shall I say, comprehensive dependencies. That is, the
The solution to RPM's shortcomings isn't to switch distros, or tack on apt4rpm etc, or anything as drastic as that. It is:
1. don't use 3rd-party RPM's.
2. upgrades...
a. if it's mission-critical, test it in a lab first, for pete's sake
b. if not, just do a fresh install, you learn something every time you do it
I'll also plug a little program I use, called pack. Pack is a replacment for
They plan to keep selling existing models, but I think that RPN on the consumer calculator is going to go the way of the dinosaur.
Frankly, this move (and the others done to scrape together money, then merging with Compaq...WTF?) does a great job of showing that execs shouldn't recieve bonuses for closing mergers.
May we never see th
How bout a gconf-ish tool, that doesn't use a stupid daemon that can break, keeps all files in xml or similar in ~/etc, or ~/gnome or ~/kde.
I've had single crashes toast windows registries(not on MY machine, windows doesn't touch this thing), and a single crash(with a network home dir though, not *quite* as bad as windows) can break gconf.
When will people fucking wake up and stop trying to copy MS, but do it right. Many MS ideas are simply Very Bad ideas in the first place and there is simply no "doing it right".
The registry is the perfect example of this.
Sticking feathers up your butt does not make you a chicken - Tyler Durden
You can take debian and .deb and that hidious website and burn it for all I care. Its a void of a distribution that its totally and completely insignificant in the market today. If Debian and all its users dissappeared tomorrow, Linux would still continue to grow via RedHat which is the leading company that is truly pushing and innvoating Linux.
And take RMS with you.
poll: Is RPM doomed?
a) yes
b) no
c) CowboyNeal
Don't complain about lack of options.
Ximian's Red Carpet is left totally out of the discussion of package management over RPM. I use Ximian on top of Red Hat at work, and am very happy to never download an RPM for the OS or Ximian's add-on dekstop other than through Red Carpet.
For the first, you're right, the debian way makes more sense. Mandrake went through a huge overhaul in the 7.x to 8.x series to use debian-style library packages, but RedHat has not done this yet.
As for #2, you can most certainly build RPMs as a user other than root. The Mandrake RPM Howto has the most concise explanation of how to do it... it's only a couple lines in a configuration file in your home directory.
WWJD? JWRTFM!!!
This will piss people off, but I stand by it.
RPM is for experts
Linux is for experts.
Just because we have better window managers that does'nt mean at the core that more people understand the internals.
RPM is better than no packagaing system, and saves time, but with all software there is and always be caveats.
Overall i'm quite happy with it, some minor tweaking like better handling of dependency's would be good, but I think the article takes it too far.
Instead of putting down 1 system, why not work on something more important like package management convergence, either we all move to RPM or all to something different.
When are we going to get support for Microsoft OS for RPM? It's long overdue. I have been waiting for OfficeXP in RPM format for sooooo long. Of course there is the problem of having Nimda distributed in an RPM package. Can anyone say cross contamination?
Sorry about the writing. Robot fingers, you know? Cliff Steele in DOOM PATROL #23
I've used SuSE, RedHat, Mandrake, Debian and a few others in the past. I keep thinking that a distribution has enough new features to warrent me changing, and then I hit the dependency problem and go back to Debian again.
This happened a few weeks ago when I installed SuSE on my old laptop because of its PCMCIA support. In the end I has so much trouble finding a RPM and its dependencies, I gave up and stuck woody on there. It took longer to set up, but I just need a net connection and apt.
I'm tempted to switch to Gentoo, but then there's always source DEBs, aren't there :)
apt isn't perfect though. Over a modem it takes a few minutes to apt-get update, and hours to apt-get upgrade, but it does make it so much easier! Also, Debian are very anal about their distro, even about unstable. There are still no (official) KDE3 or Openoffice.org debs (mainly because they don't work on all the supported platforms), meaning that we do have to go hunting occasionally.
--teamonkey
Licenses such as LGPL encourage people to make libraries.
There are two major problems with RPM and neither have to do with the underlying packaging system itself. The first is a lack of a coherent standard between all of the distros that use RPM as a basis of application deployment. The second is people using an RPM based system installing from a tar.gz.
.spec file to work on their oddly configured system.
The reason FreeBSD and Debian's packaging systems run so well is package maintainers know where the hell shit is supposed to go. If I build a port or dpkg I know where my binary, its configuration files, and man page are going to go. I can also be reasonably sure that all the other software on the system has been using the same system as me so I can assume dependancies and whatnot will be taken care of. Some RPM based distros or just old ones people happen to be using may have subtle but important file system and packaging differences. I know I can build an RPM for a default RedHat build but do I know SuSE has everything in the same place? What about some RedHat derivitive or just newer or older version that switches shit around? Since I'm not going to install 20 different Linux distros I am going to build against what I'm using.
The second problem crops up in a couple different ways. When a program is released without an RPM requiring users to either install binaries or source from a dumb archiver it breaks the rest of the RPM system. People end up with shit they cannot manage on their systems because the dumb archivers don't have any centralized management system. Hopefully there's a Makefile included to handle installation and uninstallation. Then there is the problem of people getting source RPMs and not knowing to fix the
The suggestion RPM based distros find a common ground is something that has been known for a long time but has yet to be effectively implemented. You can be different and unique by using Linux while still being practical and using a distro with a coherent design.
I'm a loner Dottie, a Rebel.
The author summarizes his article in the following points:
- An RPM-based distribution is risky to upgrade.
.deb without following Debian's policy would make a mess out of it.
- A more complex binary RPM package is often hard, if not impossible to install.
- The incompatibilities between different versions of the RPM Package Manager added anotherl ayer of complexity.
- The developers are forced to consider differences between distributions and create multiple binary packages.
.deb packages if multiple major distributions used it with conflicting policies.
From my experience in the past few years, here are the real issues with RPM:That is usually true, but it's not the usage of RPM that makes it so, but the lack of a strict packaging policy. Applying the Denian policy to a RPM-based distro can make it much easier to upgrade. On the other hand, using
This affirmation makes no sense at all. If it was correctly packaged for your distribution, it will be as easy to install as any other package. If it was designed for a different distribution, it can also happen with dpkg packages. Please note that the package manager offers a mechanism to deploy binaries, all the rest is policy.
True. RPM is a mess in the point that it is not an implementation of a design, it is being continually modified in both design and implementation. RPM needs to be stabilized, continuing development should go to a different product.
Not RPM's fault. It would happen with
- Binary packages are not compatible between distributions, unless they're statically linked and conforming to some kind of packaging standard. Dependency to libraries doesn't mean much: that particular library can be compiled with different options in different distributions. It's not RPM's. Assume that distributions are 100% compatible only because they share a package format is a mistake. Third-party, distribution-agnostic packages should obey a policy shared by all distributions, and that's one of the major points behind UnitedLinux.
- Allowing multiple version of the same package to be installed isn't a good idea at all. Packages are different in nature, some will allow multiple versions, others won't (e.g. binaries vs. runtime libraries). Doing so only makes the upgrade process harder. Debian simplified it using a good packaging policy.
Note also that, even in runtime libraries, you should replace versions that have binary compatibility. If you don't explicitly set a soname in the package name, this information is not available at the upgrade time.
- Very confuse, non-intuitive pre- and post- install execution order.
- Transaction processing and dependency resolution is too slow, due to file dependencies. As stated above, file dependencies should not be abused, and that can only be enforced by a policy.
- Too many unnecessary or confuse packaging features, such as triggers. If you have a good packaging policy, you will never need triggers. Read the librpm sources and you'll find hard-coded dependencies for a number of packages. That's stupid, and a symptom that you've done something very, very wrong and didn't notice it until it was too late because you didn't have a packaging policy.
- Moving target. Please stop adding features to RPM and modifying existing behaviour, otherwise we'll be always fighting against the package manager while trying to make smooth upgrades happen.
- Immediate configuration of packages after installation in a multiple-package transaction. Dpkg's deferred configuration is a better strategy.
Most of the other RPM problems everyone says when touting Dpkg's superiority are myths and can be emulated with RPM (even using Debian's alternatives or debconf with RPM -- diverts is something more complicated to emulate). Dpkg is indeed a superior package manager today, but what people usually see is result of Debian's policy and not a package manager feature per se.My second pet peeve with RPM is that you need to be root to build an RPM from source.
No you don't! I regularly build packages from source in my home directory. I've occasionally had silly failures because the person who built the srpm hard-wired /usr/src/redhat into it... but that's (as the start of this thread tried to make people understand) the fault of the maintainer. Not the package format.
We all know that crap is king
Give us dirty laundry!
Have you tried doing a minimal install, with ssh, but without X?
Actually - I'm kinda bluffing that it won't work here, it didn't work on SuSE so I'm assuming it won't work on RH either.
--
Hollywood representatives have publicly stated that skipping commercials is "stealing."
Anyone do this? This creates a
$ sudo checkinstall make install
If it breaks, you know you do need to install the missing package(s) after all - that's my approach :)
Female Prison Rape in NY
RPM does have some real problems. That doesn't mean that the problems could not be dealt with. The problem with one RPM not working on several distributions can only be handled by adopting standards. LSB is a step in the right direction but it does not seem to work quite yet. There should be standards for where to put specific programs like KDE and all RPM based dists should follow them. The best thing in my opinion is something like United Linux -- several distributions that use the same base system. That would be the only way you can make all distributions really compatible. I'm not saying all distributions should join United Linux, becouse IMHO they still have some serious problems, like not having a totally free (as in speach) base system. As for the problem with dependencies there are a few already existing solutions. One is apt-rpm and another is the GUI based RPM Wizard.
It isn't the packaging format really
Source Mage and Gentoo[1] are two excellent source based distros that avoid these classes of problems altogether, and unlike RPM (or debs[2]) add no burden to the upstream software developer.
Shawn Gordon of The Kompany touches on this when he says (from the article, you did read the article, right?)
Source based distros like Gentoo and Source Mage have packaging systems that automate the process of downloading, configuring, compiling, and installing all of the software on their systems from source (pedants will note there is the occasional binary package, e.g. NVidia drivers, but for the vast, vast majority of software my point holds). Indeed, this approach makes the packaging system itself less important (so long as it works properly) than the overall engineering and organization of the distro itself, and completely irrelevant to the software developer (as it should be).
This has a couple of disadvantages, and a whole bunch of real advantages. So much so that almost no one who has used a source based distro will go back to a binary based distro once they've tried it, despite the cons (in fact, of the numerous people I know who've tried Source Mage and Gentoo, both very different from one another BTW, I know of not a single person who has gone back to their old binary favorite, be it Suse, Mandrake, Red Hat, or Debian).
There are numerous other advantages I could add here, but you get the idea.
The entire article on the flaws of RPM might better be entitled "The Flaws of Source Based Distributions" which, in the age of Free Software and source code availability, coupled with todays fast processors, really ought to become a thing of the past. In fact, it wouldn't surprise me at all to see Debian, Suse, Mandrake, and Red Hat all embracing the notion of source-based distros sometime in the future
And the advantages in speed, stability, and ability to keep current with new software releases in a timely manner will only become more acute as time goes on.
So while binary based distros are by no means dead (despite my rather provocative headline), it is my opinion that the writing is certainly on the wall, and the ovservant person can already mark the shifting change in the wind.
[1]There are other source based distros as well, including Linux from Scratch and Lunar Penguin, and likely others as well.
[2]Though in fairness the Debian developers take up most if not all of that burden
The Future of Human Evolution: Autonomy
ever tried adding X to a non-X-installed redhat?
don't. it will drive you insane.
Rdhat's solution to the problem?
USD$5 per month for online updates. marvellous.
user's solution to the problem?
millions of fake accounts on the "red hat network". jeez what a waste of time.
and apt-rpm? well i tried that, and a dist-upgrade actually *REMOVED* apt-rpm, as the version of RPM that was installed was not compatible with APT-rpm, because redhat are constnalty changing the dependancies of packages to depend on higher versions of rpm to tie you in to their inferior package management system instead of addressing the real problem: rpm sucks
If we have no packages we return to dll hell. Or if everything is self contained we have a million copies of the buggy library installed. To solution we are looking for requires that something knows what's installed in the system.
> You've gotta sin to get saved.
Then don't do it! Cooker is not intended for grabbing upgrades from, it's a developer's playground (eg right now the whole thing is compiled with gcc 3.1, that definitely won't work on current releases). If you want KDE 3.0.1 you can get it at ftp.kde.org/pub/stable/mandrake/3.0.1/8.2/ (or better yet one of the mirrors). One set of mandrake 8.2 rpms, that don't have dependancies that aren't on the install CDs. I've used them, they work.
I'm not saying rpm/urpmi is perfect, but any tool used wrongly will not perform as expected.
Alex
You're right about the forums being friendly; I've been there, and they help. But asking a question and waiting a day or two for an answer can keep the pace pretty slow... I guess part of the problem is that Linux doesn't have a single standard for where things go, so whatever I might have learned doing Mandrake or Redhat doesn't necessarily help.
Yeah, I did Slackware and Yggdrasil back in the 1993-1994 timeframe. But at this point I'm not looking for an educationally challenging experience. I'd like to see a Linux distro that, well, kicks Bill's butt. Or at least is an attractive enough alternative, so that commercial developers don't think that computing is a Redmond monoculture. And that isn't here yet. I appreciate how Gentoo's core users, a self-selected group who are a short step away from "Linux from Scratch", don't want easy. But why not build a friendlier system out of portage?
And yes, the real problem is that linux distros don't have standardized places for things, or fully standarized ways of setting things up. And yes, there are at least some standards. And, as usual, the nice thing about standards is that there are so many to choose from. (Yes, that's supposed to be a punch line, but it's also true.)
First.. you mentioned it, but I'm not sure everyone got it....
The 'Unstable' in debian terms does not mean the system is unstable, it means the package dependencies are unstable. It has nothing to do with running unstable code. It means that there is no guarantee a change will not break a lot of stuff and not be fixed for a while. It's not uncommon to try to install a package and find the dependencies don't exist yet... or they exist, but are an older version. That's what unstable is all about.
Secondly.. regarding server stability.
IF you build your kernels yourself (you should), and if you are aware of what services are running, system stability is not really an issue.
I know that debian is pretty much the only system where I *don't* run hand-compiled apache, ftpd, etc. You should know what's up in your system. In this respect, no system is more stable than any other.
Wow. Industry wide support. Yay.. just what I've been waiting for.
A linux distribution so messy that you NEED an industry to support it.
okay.. I'm mixing words.. but there is a grain of truth to it.
To think, all these years, the hundred boxes I've run, it hasn't mattered.
Supporting what, exactly? What is this 'industry' that supports RedHat but not Debian? I have yet to find a single piece of software I have needed that did not work under Debian.
I run a system based loosely on Linux from scratch, which adopts a link farm approach like you describe. My /usr/bin (and /usr/blah directories generally) indeed do have hundreds and hundreds of symbolic links. This probably impacts performance, but I've not noticed it on my K6-3/400 PC with old slow IDE disks. Using some simple perl scripts to create, retarget and clean up symbolic link farms, package management is simple. The key benefit is that the metadata associating a file with its package is the symbolic link itself - it is logically incapable of becoming out of sync.
My work-around for the root file system is as follows. Each package I keep in /usr/pkg/packagename-version. Things destined for /usr/bin live in /usr/pkg/packagename-version/bin and so on. Things which need to end up in (say) /sbin live in /usr/pkg/packagename=version/root/sbin. I cp -a the contents of these root subdirectories into /.
This mechanism is a comprimise, but works quite well. I can compare files in root fs directories against those in /usr/pkg/*/root to find which file came from which package. Updating is a simple cp -a.
Why not do the same for /usr, and avoid the symbolic link farms? Primary reason is that while copying into the root fs those files that need to be there might take up 30MB or so, doing the same for /usr would mean an extra 500MB or more of duplicated data. The other reason is that for those packages which aren't too tied to their location in the filesystem, differing versions can be present on the system simultaneously.
The question as to whether we should migrate to distributions offering more sophisticated and trouble-free package management is presented. I have a solution.
I got tired of 'an RPM for Redhat. An RPM for other distros. Or even a tar.gz for REDHAT and a tar.gz for OTHER distros' (see opera's download page for an example of what I mean.
FreeBSD, baby.
I've never looked back and wished I'd stayed with Linux.
-- oodabadabaY
The lack of standards is good, in a way.
From a learning point of view, as a hobbyist system, it's fantastic. You actually learn what is flexible and what is not. I've seen far too many Solaris admins or whatnot who just can't seem to think that something might be in a different directory.. and if it is, it was done 'wrong'.
RPM sucks now and has always sucked. I honestly can't stand anything other that a good old tarball. RPM takes the control out of the users hands, and isn't linux about giving users freedom. I have not used apt-get or the others, but I have had a number of run-ins with RPM and, yeah you guessed it,... it sucks. I hope it dies a horriable death.
re: #2. Ah, I see. Too bad RedHat doesn't tell you how to do it. BTW, is that a new feature? My last experience with RedHat was 6.2.
To get something done, a committee should consist of no more than three persons, two of them absent.
Packages are way better than Windows setup.exe.
1> Consistency, everything is installed the same way, select what you want, and hit install. (I use Mandrake, and rpmdrake makes it extremely easy to install packages...
2) Non-bloatedness. I'd much rather have 20+ packages for KDE than 1 package. Yes, it'll take me a long time to go through them, but I select what I want, not what the developer thinks I want.
One really cool part about Linux is that I can change --anything--. I don't have to have a graphical interface if I don't want, in which case I don't need to install it. If I plan on using Gnome as my window manager, but want to run koffice, I only need to install the kde-libs package, and don't need all of the kde binaries..
When a small part of a large project changes, I only need to update that small part, instead of redownloading the whole package. Imagine having to download all of KDE to update a tiny KDE app.
Uninstallation is also simple, select the box, hit remove, and there's -no other prompts-.
BTW, There is an installshield for linux, it's any kind of RPM/DEB installer (RPMDrake, apt-get, alien, etc) and it's of a hell of a lot nicer and more consistent than any simlar idea on Windows
Hopefully I won't get modded down for this... It's interesting that on the same day an article critical of RPM is posted to /., there's an article announcing the release of FreeBSD 4.6. :-) FreeBSD from what I understand has a very simple and powerful package management system; in fact it's the system that inspired Gentoo Linux. It also has a huge number of packages, comparable to Debian in scope; and has nearly 100% binary compatability with Linux to boot. It might be a good idea when you have some time on your hands to give it a whirl if you're tired of RPM...Don't pay attention to the "BSD is dead" trolls.
What makes DEB files work so well is that there is usually a single bottleneck that they all go through: the Debian organization. That's where they all get tested for whether they can be installed. You may notice that DEB files are almost never distributed separately. If they were, then users would have the same problems with them as they do with RPMs.
Systems like Gentoo really don't solve the problem either. Using source merely reduces the frequency of dependency problems, not their fundamental source. That, again, may be a practical tradeoff, but you also pay for it.
So, by all means, run Debian: it really does work better. But it doesn't work better because of the packaging format, it works better because of the organization behind it and because people generally just don't do third party package distribution.
The author is smoking crack if he thinks the mass of Mandrake users are going to switch to Gentoo. Any OS that is so arrogant as to demand a huge investment in learning idiosyncracies just to get it installed is doomed to be used only by the tiny fraction of people who have a lot of two things: free time and technical knowledge.
One of the reasons us Mandrake users are asked to "download 2gb of ISOs" every six months is because Mandrake is a for-profit business. They are attempting to derive substantial revenue from new versions. And I gladly support them in this.
About the only thing that could possibly alter this ISO downloading kick would be a change in the way North Americans are charged for bandwidth. Once per-meg limits kick in, and they will, the situation will change in a hurry.
Nope, it's been that way for quite a while... certainly since RedHat 6.0, but I'm pretty sure it was back as far as 4.x, even.
WWJD? JWRTFM!!!
What I'd love to have in a package manager is a more intelligent dependency check. Like, instead of just saying "I need this version of X," it would also just check for the existance of /usr/X11R6. Or if a package requires BerkelyDB, after checking "inside" the package manager, just try and see if there's a libdb.so somewhere in the LD search path. And then mark down "inside" the package management system that the "BerkelyDB" or "XFree86" dependency seemed to be fulfilled by a manual installation.
That would be the ideal system for me.
Al Qaeda has ninjas!
The key to figuring out why a particular solution is not working is trying to figure out what problem it is trying to solve. Why do we need a package format like rpm? Because linux applications tend to consist of a lot of files which need to be put in the right places. Doing this manually takes time and is error prone. Types of files may be icons, images, executables, man pages, fonts, .... In addition to these files scripts are bundled that may do configuration, clean up after removal, move files to the right directory etc. Making this work requires that the creator of the package makes a lot of assumptions like where do icons go on this system? What is the right place for an executable? Where do the man pages go? How do I add a menu item to whatever window manager is installed? ...
.deb or .rpm is better. IMHO they are equally flawed. The only reason .deb works better is because there are fewer .deb based distributions (i.e. debian and a handfull of very small debian derrivatives). The .deb format is not plagued by differences between distributions because there's effectively only one distribution: it avoids the issues rather than solving them. Try unleashing potato based kde .debs on the latest unstable debian and you will find yourself in .deb hell (ironically most debian potato users end up trying to do the reverse: install the latest kde .debs on a potato system).
Efforts to improve package system have focused on providing answers to such questions: standardization. Standardization is good but if you take a step back you realize that it is not relevant to provide answers to these questions. Specifying that this or that icon should go to some kde specific directory is totally wrong. It is the task of the package manager to provide such information, not to require it. All the package should provide is an icon.
A package is a set of files with some meta information, not a set of files that scatter itself all over the place based on some assumptions the package creator made. Given the meta information and the files the package manager should do the rest: copy files, insert menu items in relevant menus, etc. This is how apple bundles work. Another example of this approach is the war package format for servlet applications.
There's a lot of debate on whether
Jilles
Wow, you've just described a huge aspect of DLL Hell on Windows...
DLL Hell can also be solved by intelligent people setting up install packages... Strange how that never works very well in practice.
.. To mess up your box. Even doing things from source can gat you in trouble.
RPM just speeds up the process!
\m/
So you'd have the entire world stick to a broken or painful standard so you can install by floppy? Are you kidding?
And who cares if a tiny 100k program swells by a whopping 500k if it installs correctly. Wow, this might amount to a whole megabyte of wasted space on my 80gb drive!
I encourage you to swing by your local computer parts store and check out prices on hard drives, tiger. While you're there, check into a new system for that 8088 you're using.
Talking about standarts etc.. then the RPM problem, compiling isnt an option of the 99% of the poeple (other than us ;) Talk about SlugWare, ignored, i can't think of any other reason to talk about it, GET DEBIAN!
Well, I hate to admit it, but this area is one of the fiew that Windows is still king.
.exe creates directories, updates as needed (the updates are included usually in the .exe), coppies files to directories, writes to the regestry, and cleans up after its self. The .exe installer has become _very_ efficent.
.ini files to run without incident.
.ini file for each program. Now there was a central location for _ALL_ configurations of _ALL_ of the programs.
./configure.sh And that's just to make source ready to go.
Like in other replies, there is just one file to install anything on a windows machine. The
I started with windows 3.11 and It's program install, initialization, and configs are very similar to linux. Under 3.11 the user installed somthing (which updated dependances automatically) and configured the
Then came windows 95. Under 9x and NT4 the regestry was created. Gone were the days of an
Linux, however, lacks in this arena. To just configure _source_ to be ready to compile the user/installer must go to shell and run
RPMs are somewhat better. Generaly, under Mandrake, you simply double click on the RPM you want to install and enter root passwd and you get a nice GUI to walk you through it. Usually everything goes as planned, but some times there are hickups.
Another shortfall of RPMs is the fact that when an RMP is downloaded, you _ONLY_ download the binary for the program you want to run. The RPM usually does not include updates to dependances, it expects you to fix them your self.
So, my far fetched idiea is
1) Have a central repository for _ALL_ configuration and initialization files. (like a regestry?)
2) Some how include updates to dependances to _MAKE SURE_ the program runs.
3) Have a standard that is agreed upon across the board for files to be included in an RPM and make them generic. ex. An RPM for Red Hat should also work under Mandrake. (I don't know if this is possible beacuse of file placement, directory, etc. discrepencies)
Just my idieas. A lonf way off I can tell, but I think we need to get there so that linux can realy be an end user system that is friendly to Ubergeeks and n00bs alike. I'm just a high school student that probibly does not know what he is talking about very well, but I am the only person at school to run linix on my laptop and have it work for daily usage. (notes, web surfing, papers, etc.) _PLEASE_ corect me if I am wrong about anything here. I'd rather ask a dumb question than be an ignorant.
Alex
What scares me off using something like apt-get is that my home computer is on a dial-up. I don't want to unleash some automated system that's going to go and stupidly try to jam 50MB worth of packages down my pipe. With RPMs I can control how much gets downloaded and when. And I have the nice SRPM fallback when things don't work.
How easy is Debian to maintain on a dial-up?
If you take a look at comparison of various package management (http://www.kitenet.net/~joey/pkg-comp/), it is clearly shown that RPM and DEB have almost the same set of features.
So, why installing an RPM is a more hassle that installing a DEB?
Because there are more distributions using RPM, while DEB is used almost exclusively on Debian. Yeah I know there are Progeny and Storm, but they are not very popular and are using a sizable part of Debian itself anyway. When somebody decides to make a DEB package, he will make sure his package will work with Debian (and Debian only), and he can be sure that everyone that downloads his deb will be installing it on a Debian system. But when another person decides to make an RPM package, with current situation it is a very hard job to make sure his package are compatible with various version and various distribution.
This problem will be gone if every RPM based distro are following the LSB. Even if they are all following the LSB very religiously, it is still possible to encounter this sort of problem. Say a person is using a LSB 1.0 compliant distro, but he downloads an RPM package compiled for LSB 2.0, it still won't install on his system. But still LSB is a lot better than forcing a distribution monoculture to all Linux user.
Actually, there is a limitation of .rpm that hinders the APT4RPM functionality-- file dependencies. .rpm archives depend on specific files, while .debs depend on specific packages. This can be worked around, essentially by creating a list that maps files-that-are-depended-upon to packages-containing-these.
But yes, there is at least one technical superiority of the .deb file format. I have never heard any argument that .rpms have a technical superiority to .debs, so I have to wonder: why don't RPM-based distros don't switch to deb? They could just adopt the .deb file format as RPM 5, make the tools speak deb, and stop worrying about it. They'd serve their users better and reduce duplication of effort.
Or perhaps users should take it into their own hands. Using tools like 'alien', it might be possible to take the apt4rpm approach one step further-- create an unofficial 'Redhat .deb' distribution-- the same packages as Red Hat, but in a different package format.
KDE users configuration files like most other Unix-software.
There are some things debatable about the location of these files (in $KDEDIR/share/config and ~/.kde/share/config) but thankfully it's not even close to being a registry.
Great idea, but the foundation of the complaint of Apreche is that he wants MS-style autoplay without any of the configuration management downsides of Windows.
It can't be done because this desire is unreasonable. It is not too much to ask somebody about to install software onto his machine to read installation instructions and at least grossly understand the process. If the user refuses and the install goes badly, what then can you do? Nothing.
This kind of problem resides between the chair and the keyboard, and any time spent addressing it beyond a quick slap to the back of the head is wasted time.
In computer systems management, there is a strong correlation between authority and responsibility. Or, if you'd rather: "With great power comes great responsibility."
The user must understand this. A user who will not understand this gets what he deserves, and his resulting whines should be ignored. This kind of user should just wait for the next update of his distro. Those willing to learn just a little can get their apps earlier.
That said, yours is still a kickass idea. XML is a cool idea, but I think that this could start with a checkbox front-end to autoconf-produced configure scripts. So many of the "with-*" and "enable-*" seem to be common across different packages. If it catches-on, either maintainers could add options for user-friendliness, or third parties could build the flesh-out for user-friendliness, much like contributors often create and provide binary packages in different formats.
They who would give up an essential liberty for temporary security, deserve neither liberty or security
I absofuckinlutely HATE upgrading an RPM-based system; it's why I moved to Slackware and eventually to FreeBSD.
Man, you've got a little booger on your mustache.
All the solutions the author seems to prefer (basically, switch to another distro, not RPM based, or use tools which need some distribution repositery to handle dependancies) doesn't answer point #1: How to install a random binary RPM which has dependancies not present on the system?
/usr/src/what/ever? Once it's installed with rpm -i, or even built from source with rpm --rebuild, the spec file doesn't need to know where it is, it will be in the right place.
Switching distro might help you about the "dependancy hell" of RPM, but then (as the author notes) you're at the mercy of the packagers of your distro to make it available to you. What's the difference between that and being able to only install a RedHat compiled RPM on a RedHat system? Or a Mandrake compiled RPM on a Mandrake system? You still have only one source of packages which "will work". It might be a bit easier with tools like apt-get, urpmi, apt-rpm and apt4rpm, but your distro (or some other repositery) still needs to manage the dependancies during the build and install processes. And they select what you can install (by rendering it available or not).
I don't think the problem lies in the RPM format itself (although, again as noted by the author, RedHat has sometimes changed the format without backwards compatibility). What's needed is more resemblance between the layout of the filesystem, like what the FSB and LSB (although there's more to it than only FS layout) try to put forward. That's what will make it easy to install random binary packages found on the Net, which is the core of the article.
To the contrary of M. Shawn Gordon (the Kompany), I don't see a problem with different places (among distros) to put the same software. If it's something that can be in multiple places, there's usually a foo-config script which will tell you everything you'd like to know about it. The packagers just need to learn not to hardcode paths if it can be different among users, and use the foo-config method instead.
And what's the problem with putting the RPM build area in
Personally, I use RH since 4.2. I just upgraded from 7.2 to 7.3 yesterday. I admit I didn't used the normal way (which is reboot with install CD, choose upgrade), but the longest part was still to actually install the packages from CDs. And I've got quite a bit of packages manually upgraded (normally rebuilt from source by me) from the original developers rather than RH. If those where more recent than what RH packages, it kept what was on my system before (eg, Mozilla 1.0.0 rather than 0.9.9).
Also, making a spec file is rather easy. And if you use the %configure et al. targets rather than directly call configure, a whole lot of options about the placement of files will be fed to configure for you (depending on your particular distro). Not sure which version of RPM introduced it, nor if other distros use it besides RH, though. There's even a way to build an RPM from a source tarball (although I'm not sure if you need a spec file inside the tarball or not, as I never used that way).
I ended up getting most of my packages from there, but there's no kdevelop or koffice in the 3.0.1 directory for mandrake.
If there was a reasonable standard base I would have used a suse packege.
Would have known that the packeges were at ftp://whereever,
And that still leaves the question open , why MYSQL?
IMHO RPM's need a MSCW rating system for deps.
Must have glibc>34
Sould have
Would like to update/install mysql as well.
thank God the internet isn't a human right.
The reason RPM is the most popular package manager out there right now is because it's the best. Sure, it's got some problems, but writing a whiny opinion piece isn't going to solve them. If something better gets written, something better will get used. It's that simple.
By the way, as someone mentioned earlier, dependency hell is created by poor packages. LSB should fix that; keep in mind that on an LSB-compliant system you will be able to look for a single dependency called lsb-1.0 (or whatever future version) and if it's found, you may safely assume that the system has all of the components which make up an LSB-compliant installation (libc, libz, etc.). That by itself should alleviate a lot of installation headaches.
In the future, though, I think we're going to see a lot more automated install programs. Ximian appears to do it seamlessly (unfortunately, I can't use it because I prefer KDE). I've also seen others, such as OpenNMS, do the same thing. And then of course there's the online version of CPAN that just goes out and grabs whatever it needs.
I realize that the ubergeeks among us will scream bloody murder at the thought of an installer program updating and installing libraries without asking permission. For those of us with that concern, we'll continue building stuff from source so we know exactly what's there. But for Linux's increasingly less techno-savvy user base (like it or not, folks, the Windows world is slowly starting to wake up and move to Linux) you have to make it easy.
Tired of FB/Google censorship? Visit UNCENSORED!
I must agree whole heartedly with this comment.
I'm a redhat user myself, and have tried downloading binary RPMS and seen RPM-hell first hand. I found the same solution: download the source RPMS!! A quick rpm --rebuild package.src.rpm will usually do the trick.
I have seen some cases where this does not work (some developer wants the latest ALPHA version of some library). For this I blame the developer, not the distro.
Yeah, there is couple of problems with RPM, but:
.spec file) :)
- it's easy to do upgrades (on RedHat, don't know about others) I do it several years from remote location, and only once it failed because of bad LILO configuration...
- you always know which file belongs to which package
- you can verify checksums of all installed files
- dependencies is not a problem - it's a solution to the problem
- it's simple to locate needed package from distro
- if you're trying to install someone else package, you'll better to get sources, and build rpm package youself
- I agree that it is bad idea to distribute rpm binaries only, so best is to post tar.gz source, rpm packages are optional (it is good if source includes
- and if you don't like dependencies, you can always use --nodeps
P.S. When I start using linux in 1995, first distribution I installed was Slackware, and after one year I switched to RedHat.
Slackware is a good, but you have same dependency problems (and you even don't know which package to install in case of such problem, lets say then installing some binary package). It also much harder to upgrade it....
http://checkinstall.izto.org/
I've been using RH/MDK for about 4 years now, and have had my share of RPM nightmares. Urpmi, while it is a good idea, has ruined my system (kernel panic on reboot) before, so I don't trust it. If I have an RPM to update, I *always* go to a RPM FIND site, then download/install the Mandrake or Mandrake Cooker version; then it just works. I've been much happier with this setup.
I use Mdk at work, and my wife runs it at home fulltime, and we're happy with it. After running it for so many years, I'm ready for more of a challenge, so I'm now building a box just to install/learn Gentoo. Once we're comfy with that, that will be our primary Linux. I can't wait, it seems like Gentoo is just the right Linux for ppl that still remember the thrill of getting RH 5.0 up and running!
Phil
Switching to Debian doesn't appear to have helped you with your spelling.
Try SuSE, perhaps you'll do better. It has some nice spell checker with the mail programs.
I've been using linux for under 5 months and I rarely ever use RPM's, even though I run RedHat. I prefer to compile programs.
Section 1 complains about failed dependencies when installing binary packages. Failed dependencies are a problem with any packaging system (or source distribution, for that matter) that does not include everything in the package.
Section 3, claims that RPM creates fragmentation between distributions. No evidence is offered. The author appears to be making the mistake of assuming that since several distributions that use RPM are different, RPM must be the cause.
Section 3.1, claims that upgrading is not supported with RPM, but is with DEB. This will come as a great surprise to the hundreds of thousands of Linux users who regular update everything, including kernels, via RPM. Not fully sure how the author got this part so wrong, but I think part of it is that Debian is not commercial, so when they say something is "supported", that means something different than when, say, Red Hat says it.
Section 3.2, complaining about different versions of RPM causing problems. Changes quote about why Beehive doesn't use RPM or DEB to just talk about RPM. Greatly exaggerates the problems that were caused by the one time RPM underwent a change that was not backward compatible. Again attributes to RPM along problems that every packaging system has.
Section 3.3. Continues blaming RPM for the differences between distributions.
It basically continues on that way, making these same mistakes over and over, so I'll stop now.
On Windows2k+, given a trusted vendor, I can click on a web link, click I agree, and a few minutes later have a new piece of software setup and all dependencies configured and taken care of for me.
.
:) Thus the prevalence of a C:\windows directory on NT installs, heh, sooner or latter some application starts installing crud to there. :) )
The *nixs still have problems agreeing on a standard path format. . .
(though granted MS's solution to this matter is not quite so. . . nice. Heh. They just support all of the different oddball paths ever used.
Need help treating your acne? Come here!
Package managers are intrinsically against what Linux is all about: putting control in the hands of the little guy. Building everything from source is how you get (and stay) in control.
Have you ever tried installing a Red Hat system without X, and then later tried to install a desktop?
Actually, rpms can depend on files and/or packages. Either way.
But as for switching RPM-based distros to dpkg: RPM doesn't map 1-1 with dpkg. I don't want to get into a big relgious war (although, that's pretty much this whole story...), but one thing I find technically superior is the ease with which an RPM can incorporate multiple sources and multiple patches -- this means it's very easy to take a Red Hat package, which contains pristine, original source + patches, and add my own local patches leaving the RH patches in their own "pristine" state. This is harder to do in dpkg -- requires some slight-of-hand at least.
Red Hat Package Manager Package Manager
I picture heaps of posts here saying .deb is the thing! Which means they ofcourse dont understand jack. .deb is no more sophisticated the rpm.
- "yes" you say, "apt rules!"
Guess what, there is apt for rpm also. Works just like apt on debian.
IIRC, rpm packages can depend on packages, files, or arbirary feature names that are provided by other packages.
Yeah, I thought the "Red Hat .deb" idea was probably farfetched. It's nice to know that .rpm does have technical merits-- makes it easier to understand why distros and the LSB continue to use it.
What if, when you wanted to perform a binary installation, it checked dependancies the same way that autoconf-like programs do... tries to find them in particular locations, and creates a configuration file for that program based on what it found? It can do version checking as well, and report any mismatches to the user. In situations where there isn't a clear-cut place to put such a file, the installer could create a bourne shell startup script instead. It would work everywhere, and wouldn't be dependant on _any_ rpm or deb databases.
I realize that this would require one new file (either a config file stored in the program's library directory, or a shell script used for startup), for each package that gets installed, but we're already looking at wasting space with the rpm or deb databases anyways.... this solution wouldn't take up any more space and has the added bonus of being completely cross-distribution!
For library packages, it shouldn't even need to store a config file... it can just check the versions of the software or libraries that it does require and report back to you. The job of actually finding the libraries as they are needed can be performed by the linker, which is presumably set up to search applicable directories. Heck, if it's not, even this information could be reported at installation time too!
File under 'M' for 'Manic ranting'
You can't blame RPM. RPM is merely a vehicle for installing a package. How an RPM is created is the key. Blame the user that forces the install, blame the RPM creator if they don't have a clean system. Don't blame the vehicle.
.deb's are cleaner most of the time is because they come from a centralized source and are created under fairly rigid standards so they will work on a 'known' base system. A .deb that is not officially maintained is no different than an RPM of similar background.
An end user needs to simply understand that when you compile a package you are including the base configuration of the system it is built on. If a builder/maintainer of an RPM has a system that is not identical to the user trying to install the RPM, of course you will have dependency issues.
I have never had a single dependency issue with an RPM supplied by the distribution I was using so long as I was trying to install an RPM built for the release version I was using.
Why is it so difficult for people to understand that if they try to install an RPM 'from the wild' they might run into trouble?
The reason
In a nutshell, use RPM's that were built for the release of the distro you are running and QUIT using --force --no-deps as your normal install routine. RPM bitches about dependencies for a reason, forcing the install is YOUR mistake not the package manager's.
Wow, I read the article, and its really clear to me
.deb or slackware like packages?
this guy have no clue. Read for yourself.
Besides, just because several distros choose RPM its a bad thing their packages dont work together?
What if they choose
I dont see why it should be any better?! If RH compiles packages requiring glibc 2.2.5 but MDK only
have say glibc 2.2.3. It doenst matter if you stick the binary in a deb or rpm file..
As of upgrading an RPM based distro, he says its more risky...
Ummm hu.. That might very well be true, but goddamn its not RPM's fault. Its the stupid packagers or distromakers fault. There is always
a chance things breaks upgrading a distro. Just do
it right, the packaging tool matters little..
Wow... This is one of the most factually flawed and misinformed articles I've read in a long damn time. And right after I woke up... I've got to find better ways to start my day.
...The installation fails, reporting a missing dependent package without which it will not install or function correctly.
.src.rpm instead and build that. It's easy:
Some of my bigger complaints:
LISTEN to what it's telling you. This is always the first complaint about rpm from those who don't like it. However, getting rid of dependency information DOESN'T GET RID OF DEPENDENCIES. Without the information before install, and without those checks, the software won't function after its installed. That information is absolutely critical when software has to continue functioning.
Upgrading an RPM-based distribution is risky at best
Based on what? Have you ever had a major failure? The only problems I'm aware of stem from replacing vendor packages with third party packages, which may not match the layout of the originals (or the new vendor packages.)
it has created enormous fragmentation between distributions
Nothing has created fragmentation but their own opinions about where things belong. Source distribution doesn't solve that.
developers are forced to take this fragmentation into account when creating binary packages
No we don't. Autoconf/automake follow the FHS for installation, and that's what most of us use.
with Debian, you only ever install once; upgrades are not only fully supported, but strongly encouraged.
That's not a result of dpkg, it's a result of apt. Apt is some bad-ass software, and I rejoice that it's now available for rpm. I've used it to upgrade a number of Red Hat Linux 7.2 systems to 7.3, and even upgraded one RHL 6.0 system to 7.3.
Not long ago, an RPM would work, period. The only possible concern was whether it was built against libc5 or glibc. -- Dennis Powell
Not long ago, GNU/Linux systems didn't provide many *useful* libraries for programmers to work with. libc as the basic dependency meant that developers had to impliment their own basic needs over and over again, which is one of the reasons that UNIX has not been a popular development platform in many areas.
Many of you will have remembered that the RPM Package Manager went from 3.x to 4.x without backward compatibility
Um... no. rpm went from v3 to v4 and it was backward compatible. rpm v4 could install all of rpm v3's packages. rpm 3.0.5 was also introduced, which could handle rpm v4 binary packages.
I just don't see how the distributions are going to bend over to offer concessions to each other.
Um... are you TOTALLY ignoring United Linux and the LSB? Both of these are multi-vendor efforts to standardize the basic system on which GNU/Linux distributions are built.
My own conclusion: If you have problems with dependencies, then the package was not built for your platform. There is, however, a meeting point between source installs and the benefits of rpm: The source rpm. If your binary rpm was built for some other platform, get the
rpm --rebuild package-version.src.rpm
And I thought everyone had agreed on measuring angular velocity in in Revolutions Per Minute. I bet the French are behind this, what with their platinum-iridium meter-stick and all.
My car gets fourty rods to the hogshead and that's the way I likes it!
Nice reverse psychology. Lacking a valid point, you threw in a bunch of distracting f-bombs in the hopes that everyone would assume that, underneath this inciteful harangue, you might be saying something meaningful. Fact is, you're not.
You're asserting that, because we all have broadband connections and 80 gig HDDs, there's no excuse for relying on an external package. This is a complete fallacy. There are still plenty of folks out there who are still downloading over 56K connections. They probably still outnumber broadband. There are also lots of people still using small (10G) disks. But even if everyone is running the latest and greatest, there's no reason to throw away HDD space, system memory, and downloading time by having a dozen copies of one library.
Also, as an earlier response pointed out, library systems make it easy to fix exploits. It's much easier to simply update something like the zlib package than to wait for a new version of every piece of software that uses it, and then download it. The former should be fixed within days and requires a 500K download. The latter could take months and require gigabytes.
I'll admit that the library system isn't perfect. Library developers don't always maintain backward compatability. Application developers take the easy way out by requiring "version 1.1.4b" of a library when any 1.x would have worked fine.* But your "solution" carries its own non-trivial problems which you don't seem to recognize. Or maybe you're just a troll.
* If it really does require 1.1.4b, then by all means, include it in the application.
You want the truthiness? You can't handle the truthiness!
The idea is that configuration files would remain distinctive, but each package author could provide an interface from the standard configuration program to the configuration file. (It is necessary to continue to allow hand-editing.) So, there would need to be a way to execute the interface to interpret the ASCII configuration file and write to it. XML merely describes data, I think, it doesn't have any way to cause a program to be executed.
GENERAL RANTING
.0001% security headaches, there just AREN'T. that's why the IT industry has so FEW mac "security"and "administration" people. They AREN'T needed, the average user can configure a lan, and not really worry about security or whether or not their office crap will run, because it will run, and the boxes don't "break" either.
--I have the same problem! I have a default redhat 7.2 workstation install, just gnome, no kde, no "development", no ridiculous childish games, because I am not a programmer nor a time waster.
WHERE'S ALL THE PROGRAMS? I KNOW there's more than what's in the menus, but dang if I can find them and get them to turn on! WTF is all this crap installed here, I can't even imagine a full install.
What do ya have to do, join the seekrit club and exchange class rings or something to find out? sheesh! What I have works OK, not great, just barely-I mean barely- usable OK, I have used up2date to up2date stuff, that seems to work well, but where's the other GIG of crap installed at?? where'd it go too, and WHY is it hidden from the user? Why isn't it in the menu's anyplace? What's up with that? Linux generic brag is "look, 50 zillion FREE programs". Bull and sheet, there are 50 zillion free assemblages of weird CRAPPY code that almost but not quite work. MOST DON'T WORK AND ARE DESIGNED FOR PROGRAMMERS TO USE AND TO BE FORCED TO TWEAK CONSTANTLY. Honest you programmer guys, I'd rather pay my share for professionals to actually make a product. I'll pay the money..20$ shareware for a prog that works, or 50 hours tweaking for something that *might* work? TOUGH DECISION.
There's really (what I can see anyway) only a few hundred COMPLETE actual programs that WORK AS ADVERTISED. Is there an actual NEED for stuff like 18 mp3 players, when only three of them actually work, or is the real clue this ego tripping that programmers get into, my mp3 player is gonna beat up your mp3 player SOMEDAY OVER THE INTERNET RAINBOW whenever we get to version 6.89x_semibetaalpha after we fork this and debian that and my bsd is better than your *nix that. What CRAP. It's juvenile crap.
What I see is the bulk of "linux development" goes into freeking EYE CANDY, like "skins" and "themes" and crap like that. Who **&^% cares? GUI is ALREADY invented, get a clue gnomers and kde'ers and whatever'ers.
I like the THEORY of linux, it's an interesting idea, but REALLY, what's the point? I'd LIKE to support it or one distro with my interest and ca$h, but tell ya, about ready to sell off all my x86 boxes and buy a brand new mac. I tried linux MERELY from getting a deal on some wintell boxes, used, thought I'd try it out before I resold the boxes. didn't want to load micrcrap on them, thought "hmm, heard about this linux stuff, I'll try it out". GIMME A BREAK. I tried redhat and mandrake, WHO'S KIDDING WHOM HERE? Are you guys serious, this is a professional operating system? HUH? This is at best sub beta crap, not even close to being anything anyone should spend money on, they should PAY you to TRY and use this stuff.
Like, how many WEEKS AND WEEKS of normal low level user time is worth running ANY linux when for a few hundred more bucks you can get a cast iron hardware/software platform like mac? It all works better than windows, always has, too, and zip security issues. What's not to like about that? Hundreds of manhours learning to program and tweak to save a few bucks so you can run on marginally cheaper hardware and save a few bucks on an installation CD? WHAT??? You got nothing better to do with your time but sit around and attempt to make stuff work that you can just buy for a few bucks and ALREADY WORKS JUST FINE? My time is worth more than 25 cents an hour. MAC's are EASY as crap to run and customise, and there just plain ain't even 1% of the net security worries there is in linux/unix/bsd/whocarez or winderz. Probably not even
More than 7 years on the net, never got 0wn3d on a NO FIREWALL BASE INSTALL mac. NEVER, EVER. No virus, no trojan, no nothing. Mac classic I used for years and years, it works. It just plain works. OSX don't know, never used it yet, but on a new fast machine, mac classic will still be useful for more years and years. I think apple is completely bone idiotic to abandon it, IMO, for this semi open "unix" "linux" bsd/mack/micro/macro "kernel"of misery crap. All they need to do is keep making the best hardware, it'll sell. Linux is lowest common denominator hobbyist stuff for people who don't like going into the scary outside whirrled it appears. It's also gone consumer fraud now bigtime with linux "experts" selling themselves to companies, it's job creation fakeouts mostly. Unix is crapola for the desktop, it SUCKS and it's gonna take a decade to get to the point the average person who isn't a software engineer to use. Ya'all linuxers need to acknowledge that. You can't even agree on HOW TO INSTALL A FREEKING PROGRAM YET. that's what this thread is about, hundreds of guys arguing about how to install a program. Step back, look at that from an outsiders viewpoint. It looks RIDCULOUS. and tyou want people to actually take this serious? WHY?
That's my two bytes worth-and I am NOT trolling either- on linux after three/four months useage. It stopped being fun after re-installing the third time, getting rooted twice, and still having to delete modem and re add it just to get freeking online, and having to figure out how to do firewalls that may or may not be working as I type this. They probably aren't, and judging by the DAILY sheer volume of "security alerts" it's NO better than crappy microsloth winderz, either. No better whatsoever. It's just as crappy. There's no way to tell short of becoming a unix security expert over a years time or something. What's the point again? Oh ya, slightly cheaper and "Open source"- WHO CARES? I can goto the carlot, get some car from generic motors that runs, or start by digging my own iron ore, inventing steel, learning to forge, and etc.. and in a few years come up with a YUGO. Yes, maybe it will be cheaper, but I want a car that works right now, not in ten years.
The difference between "open source" and a commercial OS is just a few bucks, ie, take redhat-60$, mac 9, 80$- SO WHAT? 20$ difference is WORTH all this headache for something that only works about 1/10th as well? DOWNLOAD 2 gigs of crap and HOPE it works? Huh? Why is that worth it? OR, spend 6 months downloading and learning how to do stuff that is still broken and buggy.
Linux is INCREDIBLY complex for what it ATTEMPTS to do, INCREDIBLY, it's a rube goldberg accumulation of thousands of chunks of bad semi finished code, and there really isn't a way for a NON programmer to use it beyond a package distro install then start sweating. And I mean sweating.
Look at this very thread, all kinza linux experts who STILL detail incredible problems. I NEVER had any problems installing ANY mac program, you download it, double click on it. It's installed, AUTOMAGICALLY, and it WORKS. GEE, A SYSTEM THAT WORKED 15 YEARS AGO AND STILL DOES. You read the download notes "runs on mac 7.xx or 8.xx or whatever. Click on the appropriate one. hangout, it downloads. double click. EVERYTHING GOES WHERE IT'SUPPOSED TO GO, AND YOU GET TO FIND IT AND USE IT REAL EASY LIKE.
This is somehow WRONG??? Say what????
Linux is reinventing the wheel by designing something square on a spindle and having 50,000 laid off or hobbyist programmers all carve little tiny slices off of it, in the hopes you'll end up with something called "round". That's linux in a nutshell, it's for professional students and for guys trying for job security because it's so **&^% complex any business that installs it has to have a system administrator full time. That's why IBM and companies like that like it, mega buxx forever and ever, you need their expertise. That's why redhat likes it, you need to hire a linux guru to keep it working. Linux is just another deal like microsoft job security, two sides of the same coin. I call it "mac denial", same as I heard from clueless windows users who always put down mac classic without ever actually using it.
I think the reason guys like linux is that most of them are sitting on intel boxes, grew up never being exposed to macintosh, got absolutely NO clue how easy mac has always been, come from a windows or unix background then migrated to something else called "linux", and let their egos get in the way rather than trying out mac from years of putting macs down, and are bound and determined to keep chipping away at their square clunky running intel boxes until they actually work. TALK ABOUT CLUELESS. This is a duh.
I'm about one more problem away from abandoning linux/unix and switching back. I gave it a good shot, but dang if I am gonna spend multiple hours a day to try and make stuff work so I can USE my computer SECURELY that I KNOW I can just "do" by spending a paltry few more dollars on hardware and software. I want to USE a computer, not build it from scratch and hope it works. MOST people are the same.
Maybe in TEN years linux might make it to what mac was in 95, MAYBE. I DOUBT IT after reading slash dot for a long time, WAY too much non-cooperation going on.
Too many cooks HAVE destroyed the broth with this home brewed unix/linux/bsd stuff. Ya'all debian is better than gentoo is easier than slackware and is slicker than united redragondrakehat stuff guys are pushing rocks uphill, I mean BAD. Hitting yourselves on the head with software hammers because it feels so good when you stop. It's silly.
"I can install a Red Hat Linux server on a clean box in all of two minutes from initial power up to fully functional reboot"
What drugs arey ou taking ?
It seems to me that the most important thing is to make sure that the GUI is the best possible for configuration. An expandable tree in a linked document seems excellent. There needs to be a way to address every part of the tree from the command line; there should be bookmarks.
It would be necessary to write modules for every supported file format, as you say, but this could be made easier by supplying standard libraries of interface programs. Each module author could modify a module that already existed.
I used redhat for a bit, but i love apt-get in debian. Its really useful esspically if u have a good net connecton. It'll autoatically get the dependencies from othre servers that it knows. And there's only 1 format for debs.
Yes, I've been corrected on this already-- file dependencies are not the only option. It does look like the mere existance of file dependencies is problematic, though.
Another important problem is that last time I checked Deb could not be signed, while all RedHat RPMS at least are PGP signed. The last time I heard about that on debian, they couldnt agree on a way to make signing meaningful... RH signs all its packages with one key, but that would be hard for deb...
I stopped using RPMs a long time ago because it was my number one stumbling block to using linux. Defend RPMs all you want. It won't change the fact that new linux desktop users are going to hate it. Sure, if you know what you are doing you can tame it. And I've heard all the arguments about "But now that you have APT-RPM..." and still don't believe newbies, or those who have no interest in learning the gory internals of RPMs thousand and one switches are going to care on damn bit about improvements in RPM. Generally speaking, people like things to be easy. Many of these people find Debian, Slackware, or Gentoo eventually, if they don't give up altogether first. For the record, I gave up on Redhat, SuSE, Mandrake, and even beehive for the same reason: RPM. You can argue all day long about how I must be an idiot because I don't like RPM but I am in good company. And for those who didn't actually read the article, the author says quite plainly that RPM is FINE for server installs, but is failing on desktops. I have used Slackware for a long time now quite happily. Recently I decided to give Gentoo a try and am unlikely to use anything else any time soon. I have found peace and happiness in linux at last.
Russian Russian Russian RussianDollSig DollSig DollSig DollSig
unlike disk space, memory is still expensive. and shared libraries save memeory as well. if every app loaded up its own copy of glibc, you'd be throwing away at least 2 megs of memory per app. Sure, using proper archive libraries, you could cut that down, but its still rediculouls to have 100 memcpy routines in memory at once.
You say that as if RPM can do dependency based on files only. This is not true. RPM can also do dependency based on "capabilities" which are provided by other packages. Observe the "-q --provides" option. The choice of depending on files or capabilities or both is up to the packager.
"I have a good idea why it's hard to verify programs. They're usually wrong." --Manuel Blum, FOCS 94
I would love to d a redhat like distro only removing rpm and putting in the BSD package management system. But I don't have the time right now. Maybe I'llopen a project up at sourceforge.net.....
Only 'flamers' flame!
Therefore I had to turn to packaging the software I download. I started using the native solaris packaging mechanism, but it has a number of short falls.
I then stumbled across rpm. How it has saved my life:
So for me RPM is vital to my work as a Solaris administrator.
-- Thou hast strayed far from the path of the Avatar.
Anyone remember what happened to Monkey.org recently? Seems some clever person trojaned copies of fragroute, dsniff, and (maybe..not sure) fragrouter and left them there for people to install. Guess what the source based systems did? On Free and Open BSD: cd /usr/ports/net/dsniff && make install...backdoored! Don't get me wrong, I love Free and Open BSD and the benefit of the ports system, but this is a huge problem waiting to nail us. How many packages are out there on less than cared for / secured web sites waiting to be trojaned and subsequently installed by source based distros like Gentoo? There must be some control put in place before your face OS installs cruft from the net, at the very least MD5 checking should be mandatory before the file is DL'd and installed.
A: Yes. Next question.
Nathan's blog
> APT is what makes debian's package management so
:)
:)] fully agree.
> smart, not dpkg.
Sorry, but you've got it backwards there.
"APT makes Debian's package management so easy to use."
But what makes it smart is the Debian Policy that states exactly how packages should behave, not the "Guidelines". The difference is that not conforming to Policy is a "Serious" bug (read: Release-Critical) , whereas guidelines do not convey the same sense of absolute necessity.
As the old chinese proverb goes:
"When the wise points at the Policy, the fool watches apt-get"
Note that most Debian developers are not paid to work on their packages, they do it on their free time, so your comparison with RPM packagers might not hold 100%. The one tool that truly helps is the bug tracking system, (http://bugs.debian.org) and the great number of users that provide bug reports and patches.
The culture you're referring to is a strong driving force in striving to achieve excellence.
Consider this a corrective patch to your original post with which I [almost
-- don't discount flying pigs until you have good air defense
I don't remember needing any slight of hand to do this. apt-get source foo, gets the pristime source and the patches. Copy the patched source dir, make my changes, and diff against the original patched source dir. There i go. Later, get the upgraded version (apt-get source foo automatically only downloads the new diffs, using the old upstream sources (unless, of course, it's a new upstream version)), apply the patch, and there i go again.
If you don't want to use apt-get, download the .tar.gz, .diff.gz, and .dsc files by hand and dpkg-source the .dsc to have it unpack for you. Or do it by hand with standard tools, you'll just have to remember to chmod +x debian/rules that way.
I'm having a great deal of trouble seeing your technical superiority here. The only possibility i see here is if rpm would automatically try to apply my patch after applying the distro's patches, which likely as not is going to fail anyway. Please explain.
--
perl -e'$_=shift;die eval' '"$^X $0\047\$_=shift;die eval\047 \047$_\047"' at -e line 1.
Sticking feathers up your butt does not make you a chicken - Tyler Durden
Absolutely. The points raised in the article have _nothing_ to do with the choice of RPM as package format.
.tgz is magically superior to .rpm. In a parallel universe where Slackware used RPMs and RedHat used tarballs, the argument 'switch to Slackware' would be just the same.
Point one: dependency hell. When you install a binary package it requires several updated libraries, each of which may require other upgrades... well yes, of course, if it's built against a particular library version then it may require those versions. At least with RPM and other packaging tools you get a warning about what is required. Don't shoot the messenger.
The comparison with Debian: it's just because Debian put lots of effort into upgradability, and most RPM-based distros don't worry about it to quite the same extent. Talk to someone who started with Corel Linux and wanted to update some packages, and you'll see that the choice of RPM vs dpkg vs whatever doesn't matter here. Just the quality of the packages themselves.
RPMs being awkward because files are in different locations: any binary package will have these exact same problems, as long as distributions use differing conventions. This is just the familiar complaint about there not being a single Linux standard which all distros follow.
Then the author goes on to talk about using apt-rpm or Debian, totally missing the point. The reason these tools work so well is a good *collection of packages* put together by the maintainers of those distributions. It's not related much to package formats, beyond some really basic dependencies. The 'switch to Slackware' arguement is similar: Slackware's more upgradable because the packages themselves use the same conventions from one release to the next, not because
As far as I can tell, the Distrowatch article is just complaining that it's not always possible to pull random binary packages off the net, install them on your system, and expect them to interoperate with other random binary packages built by other people. Well, duh.
-- Ed Avis ed@membled.com
i suggest doing
rpm -e rpm quickly
and reading this guide on apt-get
apt-get.mine.nu
Let me clarify: it makes it easier to maintain packages with multiple patches (and multiple sources -- you seem to have ignored that), because your final source package includes both the original source + RH (or whatever) patches and perhaps source + your own patches and source -- all separated neatly. In your scenario, where are you keeping *your* patch? How do you give it to other people?
I use GNU-Stow and it works fine for me. To use stow, you have to compile sources package, install the package in a directory (/usr/local/stow/mypackage for example) and then, you "stow" all your package. Stow makes symbolic links between your package and the target directory. For example, I am in the /usr/local/stow directory:
stow -t /usr mypackage
I select /usr as a target directory and stow makes symlinks between all files in the mypackage directory and the /usr directory. All binary files in the /usr/local/stow/mypackage/bin go into the /usr/bin directory, etc ...
So now it's relatively easy to manage packages.
You just need to compile sources packages (not as so difficult as installing a rpm package).
If you want to remove your package:
Unstow it,
and rm -rf /usr/local/stow/mypackage
and everything is clean.
You can find stow at:
http://www.gnu.org/software/stow/stow.html
Your sincerely,
Yann COLLETTE
I admin RedHat servers, development workstations, etc. If you set it up properly, you can run "up2date -u" and it will automatically update all of your RPM's. No one seems to have mentioned this... I guess because the tinfoil-hat brigade doesn't like "registering" with redhat (via rhn_register, necessary to make up2date work).
I can also go to https://rhn.redhat.com, login, and schedule my machine to automatically download the latest revision to some RPM. It's free if you only do it on one box.
I've had zero dependency problems since I became an up2date fan. It really should be mentioned with the above article.
Check out the ROX app dir system:
:)]
http://rox.sourceforge.net/appdirs.php3
I really wish all applications on Linux used this system.
[All apps putting all types of shared code in a single system directory? Sounds like my C:\WINDOWS folder
Is offer an interactive mode of execution.
/usr/local/lib/libfoo.x.y.z.so, and the RPM program will add that one file into its package database so later on, it won't have to ask that dumb question again.
When installing a package, if RPM can not find the RPM dependency, it should tell the user:
"Unable to find libfoo.x.y.z.so"
Then ask:
"If you do have libfoo.x.y.z.so, enter the path so an appropriate entry can be made in the rpm database"
The user can then type in something like
If the user doesn't type in anything, then RPM should then quit and refuse to install the package.
You're playing with fire mister.
PS in case I want to try this what exact kernel version did you use?
You are talking about static linking for everything - it could work until some point. One of the points is disk capacity - when instead couple kilobytes for simple program you'll have couple megabytes, and instead couple megabytes for complex program you'll have couple hundred megabytes...
Another point is memory considerations - when you load dynamically linked program into memory you load dynamic library as well, and when you load another program, using the same library, you use preloaded dynamic library. Well, you also save on loading time for second program. If you load two static programs - you just load the same binary into memory twice and if you load more you could exhaust memory and start using swap. Then your box perfomance go down the drain...
Current state of software could be characterized by one word - BLOATED.
You just want to replicate it everywhere... Make it MEGABLOATED.
It definately covers how to do this in Maximum RPM, which is on rpm.org.
http://www.rpm.org/max-rpm/
Macintrashes have plenty of shortcomings for sure, but one of them isn't the library mess, c'oz the binaries carry everything they need with them.
Source RPMS almost always work even cross-dist. (ie. here using RedHat source package on an older mandrake.) Binary doesn't work, get SRPM, it doesn't extract? use alien, then put it in the right place on the system you need it for /usr/src/<whatever>/RPMS/...
(alien wasn't on the box, so I used another box
to extract) log:
[root@basquette djbdns]# rpm -ivh daemontools-0.76-2memphis.src.rpm
only packages with major numbers
Er, yes they are. Unix has sorted files by their type, rather than what application they belong to, for a very long time. This allows, for example:
If you want to address the files by what application they belong to, that's what a package manager is for. No distribution's packages can use
Using apt-get with cdroms is simple - you add lines to /etc/apt/sources.list referring to specific cd's. Debian has this feature and it is quite user friendly. I don't remember the details as I don't use it myself these days.
>Have you tried doing a minimal install, with ssh,
>but without X?
>
>Actually - I'm kinda bluffing that it won't work
>here, it didn't work on SuSE so I'm assuming it
>won't work on RH either.
Works just fine. Just because two distributions are rpm based doesn't mean they make the same mistakes.
Actually, the only thing that Red Hat makes you install is the "base" package list. Comes to maybe 200MB and contains, IMHO, very little crack rock. About the only things I might be inclined to strip out are slocate (not exactly a good thing on high volume servers with millions of files), gpm and mouseconfig (sixty servers, no mice).
Don't take this as a personal affront, but it constantly amazes me how ungrounded in reality many people's complaints against Red Hat are; e.g. they turn every service on by default, they don't test their software before shipping it, their minimum install is bloated (feel free to take offense at that, if you must), they're not striving for LSB compliance, etc, etc.
There may be some cases where they were guilty in the past, but they've done a more than adequate job of responding to issues when they crop up and are, IMHO, one of the better distributions out there.
Matt
I have a script I think will work; email me (jcast at ou dot edu) if you want a copy. /. thinks it has too many ``junk characters''.
There are reasons why democracy does not work nearly as well as capitalism.
-- David D. Friedman
I have. You just hear these arguments less because, in my experience, there's honestly more Debian people who seem to want to bash people over their head for their choice of distribution.
so I have to wonder: why don't RPM-based distros don't switch to deb?
I've been a RedHat user since RedHat 3.x times ('96, I guess) and I've been using RedHat exclusively after upgrading my last Slackware box with RedHat 4.0 (still '96, probably) and currently I run 9 RedHat machines.
And guess what - I've never experienced an "RPM dependency hell" in my life! Just two simple guidelines save me every time:
In other words, whenever you have any kind of precompiled binaries, there always will be problems with the binaries requiring different libraries/etc. There are only two ways of dealing with these problems:
I think the original writer was missing a point. (Or maybe I missed him not missing the point.)
.spec file and wrap my own RPM. If I have to configure and compile it myself, I ./configure --prefix=/opt/programname-version, which allows me to fairly painlessly get rid of the program.
I believe the reason why people use RPM-based distributions, like Red Hat, is that they are stable, tested and polished. When you use the ISO images to upgrade your Red Hat, yes, you wind up installing a lot of stuff. But on the other hand you wind up installing stuff that Red Hat has verified will work together. To reap the benefits of that is well worth a couple of cdroms.
Perhaps another reason is that the biggest RPM-based distributions, like Red Hat, SuSE and Mandrake really have added value when compared to the sexier non-RPM distros. You get tools that simplify management. You get a system on which everything just clicks together.
I have used Gentoo. It's pretty ok, but when you have used Red Hat before Gentoo, you'll be disappointed. A lot of things you take for granted in Red Hat, just aren't there. It takes a lot of time to tweak everything to get a system with the same features as Red Hat.
Someone commented that they've never seen anyone go back to an RPM-based distro after trying a source-based distro. Well, I have. You can read my Slashdot Journal if you are interested in the details.
Interestingly, I have never had too much trouble with installing RPMs. I realize that an RPM created on SuSE probably does not work on my Red Hat, so I'll try to find a Red Hat RPM. Many times I'm in luck. When I'm not, I grab the SRPM and failing that download the source. I might even spend a bit of time to see if it would be easy to write a
Gentoo's install makes it possible to install it in many different ways, as theres no big gui front end to get in the way.
My install:
had debian installed on one hd(ext2), and also had a 60gig with random stuff on it (fat32). didnt want to loose either
made a disk image on the 60gig, mounted it (-o loop), extracted gentoos base to it, chrooted, fully installed inside the disk image.. then used some boot disks (ironicly, debians install disks, as they had the best drivers) to mount everything, rm -rf everything on my debian install i didnt want to keep, and copied everything over.
works fine and I didnt loose anything.
-semi
Can anyone part of this discussion, provide information about rpmlib(PatchRpm)?
With this rpm lib it seems possible to "fix" an installed rpm package with
a patch rpm. The patch rpm provides the patched files only. This is very
very bandwidth friendly, but is messes up the dependency adminstration when
using apt for example. SuSE is using this mechanism with their latest release.
Any pointer towards
the inner workings patch rpms are highly appreciated!
In my experience both Red Hat and SuSE are terribly difficult to install without X and all kinds of stuff. Really annoying when all you need is kernel, shell, ssh and enough to make that run.
While a source based distro means you need gcc, bin-utils and friends, you can get a long way without X. And if need be stuff like gcc can be installed in a custom location, possibly mounted on a spare drive/partition, which can be nuked after install (simplified I know... You need libraries or you must make things static, believe me, been there, done that...).
The only thing you need binary distributions for are boot-strapping. And for that you need littele more than the build environment.
Well, for a lot of stuff the only safe way to disable, or enable, dependencies is in the configure phase of building. If the app was build to expect a library, its behavior without is absolutely not garantied to be the same as if it was never build for it.
Install rpmfind... /path/to/RPMS/rpmfind..rpm
# rpm -Uvh
Upgrade entire system handling all dependencies...
# rpmfind --autoupgrade
Upgrade specific package handling dependencies...
# rpmfind --upgrade
Install specific package handling dependencies...
# rpmfind
Search for package...
# rpmfind --apropos
etc...
rpmfind solves all your rpm problems for RPM based distros...
And, if you have KRUD (Kevin's RedHat Uber Distrobution), you all ready have something like rpmfind:
Install package...
# krudfind
Upgrade entire system
# krud2date
The problem is not the filesystem. Only users uncertain about the FileSystem Hierarchy Standard or the basis of the POSIX layout could make that mistake. Once you start installing your own files, you'll find most of them goto /usr/local/share, which, for a Windows, is much the equivelant of C:/Program%20Files.
The problem with RPMs comes out of the libraries used by the individual compiler. The most noticeable of these is when an unsuspecting regular GNOME user tries to install a binary constructed by a Ximian GNOME user. Most often when you're told by your package management utility that the particular package has a dependency issue, over fifty percent of the time, I would bet, it's really complaining about a library someone else has that you don't, and the remainder is typically a particular application it was designed to use. If you installed from sources, you would see, and I'm saying from experience, around 85% of these problems dissipate. A large part of this in thanks to considerate programmers who put the time to write alternative configure lines for the to-be-abstracted make file.
If
Ditto on make uninstall too, oh, and don't do the && rm -rf if you think you're going to use make uninstall.
For all other questions about POSIX, feel free to pickup this handy guide
For anyone else with actual standards questions, my email still works (just in case those of you who still care about standards, both of you, still want some guidance).
"Yeah...it was the numbers that were irrational, not the murderous cult of vegetarians...." -- Hippasus of Metapontum
I have upgraded various versions of RedHat in the past and in general the upgrade worked very smoothly. I am typing this on a box that was running 7.0 originally. Later it was upgraded to 7.1, then to 7.2, then to 7.3. The upgrades worked very smoothly. I have also upgraded production servers from 5.1 to 6.0, from 6.0 to 6.2, from 5.2 to 6.2, from 6.2 to 7.2, later this week I will upgrade one of our servers from 6.0 to 7.3 and, frankly, I quiet expect this upgrade to work. Yes, you have to be very careful, keep the backups around and make sure your disks are partitioned so that the latest version of RedHat will fit on them.
My $0.02
The real reason it is such a pain to work with rpm
.*.SRC.rpm". So, if someone posted a binary package that works only on SuSE but you need to run it on RedHat, just get the source RPMs and rebuild them.
packages is that the distributions are so fragmented. You can't expect the packagers to build an rpm for five different versions of redhat, suse, and caldera and post that on his/her site. So, your milleage may vary. Possible solutions to this:
1. If possible, stick with a recent version of RedHat. Almost always you will find packages for it.
2. Use SRC rpm packages. Recently, I discovered that I can just rebuild the rpm package from source on my system with command "rpm --rebuild
3. When trying to install something first look if your distribution already has a package for it. RedHat for example now comes on three CDs, that's quite a lot of packages there and all of them are guaranteed to work. You might also try to grab packages from the next version of your distribution but that might be tricky.
4. Finally, use the source Luke. I am tired about
all this whinning and packager wars in the Linux community. Do you know that on other operating systems (e.g. Solaris 7 and older) users have to compile by hand even the basic things like bash and ssh? But that's only after you get a gcc binary that works. Fortunately, with Solaris 9 they now bundle tons of freeware software, but still, lots of stuff will just have to be compiled by hand.
Another problem with the rpm packages are dependencies. This problem is much harder to solve and it is not specific to rpm only. Unless the packager has setup some sort of dependency list for apt-get or autoupdate (rpm) users then, you still have to make sure that you download all the required packages by hand and install them. Debian has avoided this problem mostly by packaging all cool software in the distribution. However, the extremely slow release cycle makes much of that very useless. For example, the current stable version of debian comes with openssh 1.x which does not support SSH protocol version 2 and the openssl version in Debian is so old that the latest version of openssh will not compile with it. So, you have to get a more recent version of openssl, and then install openssh. I know that there might be deb packages somewhere out there, but I just prefer to build the thing from source.
My $0.02
I know from my experience that programs will compile from source and run just fine on Slackware without tracking down and compiling every bizarre dependency that RedHat hangs on that package.
Maybe what's lacking is a standard way to determine dependencies?
-- Slashdot: When Public Access TV Says "No"
I think RPM (or any other binary package format) is nice because it can save users the time to compile packages. However, it has a few problems. First of all it has the inherent drawbacks of precompiled software. It is compiled for one kind of machine, meaning it won't run on incompatible machines, and will lack optimalization on others. Some packages are even specific to a given distribution. Secondly, the built-in dependency checking is flawed, because it requires that dependencies are installed as RPMs, and if I am not mistaken, won't take a later but downward-compatible version of a package as satisfying the dependency. This made me end up installing everything with --nodeps (at least I think that's what the option is called). For a while, that solved my problems, until I tried to upgrade my libc and broke the system. Since then I have never used RPM again, except for a few packages that I could only get as RPM or failed to compile from source.
/.-readers know that), which doesn't have the aforementioned problems. It compiles packages from source, and detects dependencies even if they were installed via a different mechanism, and automagically installs them if necessary and desired. Gentoo Linux adopted this system, and I am very content with it. The only thing I have against it is that it keeps the ports tree on your local harddrive (I believe Windows does the same with driver information), which takes up a lot of diskspace for no good reason, because the tree has to be synchronized every once in a while anyway. Also, without a (fast) Internet connection, it gets you knowhere. That argument doesn't count for me, however, because I myself am not going anywhere without a fast Internet connection anyway. Moreover, the packages could theoretically be put on CD or other media, why not? I think the system could even be modified to search for precompiled packages first, to save on installation time.
.deb or other package formats (well, Peanut Linux's .tar.bz2, but that doesn't really qualify for me), but I think ports (or emerge) is the system of the future.
*BSD has a system called ports (I guess many
I believe that ports comes close to the perfect package system, and could easily be modified to in fact become that system. My experiences with it have been far better than with RPM, and it's easier to use than manually installing from source. I don't have experience with
Please correct me if I got my facts wrong.
By building a distrobution-maker we can achieve
what UnitedLinux might have achieved if it were
made for desktop, consumer-based distrobutions.
Idea: Use Debian to build a generic Linux base
and have the distrobution-maker utility allow
users to add applications, themes, and
reconfiguration scripts to build their own
distrobutions out of it. Give the generic base
distrobution a free to all developer's list like
Mandrake's Cooker and stay FAR from any mention
of per-seat licensing. And make absolutely
sure of LSB compliance.
Then an army of new distrobutions will arise
that are all very compatible with each other.
While the big server markets are saturated with
the big Linux distros, these will most likely
focus in niche areas and the desktop markets.
Mandrake, Red Hat, SuSE, et al. will not have to
listen to users--it's a game of the survival of
the fittest. The greater diversity the greater
the chances of a newer, stronger rival who
will get it right and make us all happy.
I would really like to do this. Maybe someday,
if I find other *CAPABLE* volunteers, then we
will.
Matthew
Another issue that goes along with libraries is where do applications place their header files? I have had major issues with this. Typically, what happens is old header files get mixed with new header files and when you go to compile an application it will many times get confused (include wrong files, etc.). If libraries had their own seperate directory, then you could place all header files there too. Imagine how much developer time this would save. I don't know if you use GTK+ or GNOME style libs much, but they have scripts written just so developers can link to the library easier (gtk-config, *-config). Type "gtk-config" at the command line to see what I'm talking about.. I'm sure you have it. Imagine how simplified linking to an application could become. Instead of needless -I and -L we could just do something like: --usepackage gtk+-1.2 and the linker/compiler would know exactly what needs done.
This is a serious problem. Think about why KDE and other medium to large applications are using
I'd really like to get my hands on a Mac w/ OS X. It sounds really cool and I've heard many good things about it...
Dijkstra Considered Dead
yup, you can download a debian package source and make your own .deb package with just the standard apt-get. just type:
apt-get source { package name }
which will get the package source. you can then fiddle with the compile time options, and then type this
dpkg-buildpackage -rfakeroot -uc -b
and voila, a custom built deb package, all from source!
jerrold.
I have used NetBSD on servers, and was highly impressed with the ease of installing via their source based distro tree (pkgsrc). No comments I have seen have discussed it or compared it to the Linux solutions. Could someone contrast and compare, for my edification at least?
"I will trust Google to 'do no evil' until the founders no longer run it." Hello Alphabet.
Did I get it?
parse all configs to /proc in XML format (or even better RDF) - let's stop Babilon Tower at last.
Less is more !
I composed this as private feedback to the author of the article, but then thought I'd post it here. I realize it overlaps some of the other postings, but there are some ideas I didn't read elsewhere (especially at the end), so I decided to post it anyway.
.deb-based distros, you'd very likely see similar differences. Ditto for source-based distros, except for the download, build and install infrastructure, that could be easily built atop RPM. Except that having a package build from source on every client looks like a waste of time to me, if the resulting binary will likely be the same. If you want differences, you can get them and then build from sources, but if you don't, why bother? Admittedly, configure tests for present features may reduce dependencies (at the cost of limiting features of the resulting binary), but then, you can expect to get the same effect by downloading the SRPM of a package and building that.
.rpm to .deb, .tgz, etc (or the other way round, if you prefer :-) The package formats are different, to address issues that the older format could not address. Surely keeping the same name for the package manager may be confusing and misleading, but given that it's still conceptually very similar, and fully backward-compatible in the source level (by source I mean spec files), it's reasonable to retain the same name. I wish the upgrade path had been smoother, but if you think about it, it's not really possible to get more than what was gotten. Letting older versions of rpm install packages that make use of features they know nothing about is definitely not a good idea.
:-) to RPM: RPM is about managing software installed on a machine ensuring that dependencies are fulfilled and conflicts do not arise. It is not about locating packages, selecting which version of a package to use based on some criteria, downloading them and then doing what RPM does today.
Having recently turned from someone who disliked RPM and liked to build everything from source myself to an RPM-supported, I have some comments to make regarding your discussions about RPM.
First of all, I must say that I work for Red Hat, but in the group that was formerly Cygnus Solutions, that develops and offers support for software such as GNUPro. Our group is not focused on Red Hat Linux, and we seldom release software in the form of RPMS, so I don't think I can be qualified as having any bias.
First of all, I don't see what the problem with RPM upgrades is. I mean, it's nothing inherent to the RPM format: it's just that, unfortunately, not all RPM distributors are as careful about converting configuration files in case changes are necessary as Debian packagers are. Also, there's the issue that, as soon as you install packages from third parties that are not part of the distribution, and that therefore don't have an upgrade path at the time of the distro upgrade, introducing potential conflicts that are beyond the scope of what any distributor might be expected to be able to cope with. Unless, by `coping with it', you'd prefer the upgrade to refuse to proceed because of such conflicts, requesting you to remove the packages that are in the way before going ahead.
As for the variation between distributions that use RPM, that give headaches to RPM packagers, this is just a symptom of the large number of distributions that have adopted it. If there were several major
I believe the RPM version issue is a legitimate complaint, even though I'm aware of only one major RPM upgrade that has introduced backward-compatibility issues. Admittedly, I may have failed to notice smaller issues for not keeping older versions of RPM-based distros running to the point of noticing problems with newer packages. However, the major RPM change I'm aware of is IMHO not too different from say a distro switching from say
WRT the issue of getting some piece of software to automatically locate dependencies, resolve them and install them, I have mixed feelings. I don't think having RPM do it is the right place: it goes against the Unix philosophy that every package should do something very well, instead of trying to solve all the world's problems, but doing this one thing in such a way that additional layers of software can be added to extend the set of problems that can be solved.
Dependency resolution is something alien (no pun intended
As you've mentioned in your article, there are other packages built atop RPM that take care of the issue of locating and downloading packages. Not only urpmi and apt*rpm, but also up2date (and current) and Red Carpet.
up2date is the only one of these I'm familiar with, but it does as much dependency resolution magic as I've ever wanted. If I tell it to install a given package, it will find out whether there are any dependencies that I'm missing in my distro, download them and install them along with the requested packages. No dependency hell.
Unless, of course, I'm trying to install packages that have conflicting dependencies, or packages whose dependencies are unknown to the up2date server. Surely, someone could come up with a world-wide infrastructure to locate RPMS that would enable an up2date client (or server?) to determine packages that could satisfy dependencies of an arbitrary package that I wish to install, then proceed to download and install them.
But the very notion of having software downloaded from arbitrary servers ``out there'' and `automatically' installed on my machines is scary. Why would I trust such software to the point of installing it on my machines? But then, as I limit the set of trusted servers/signatures I'm willing to have installed on my machines, the likelihood increases that I'll try to install a package whose dependencies cannot be fulfilled by packages in such a set.
This model works for Debian, as well as for Conectiva's RPM-based apt-get, because there *is* a set of trusted servers that very likely carry all dependencies you may need. If they don't, you're just as out of luck. It's a matter of coverage of dependencies on the servers.
Now, let's assume for a moment that someone comes up with a distributed RPM dependency solver. A P2P system thing to which people could upload/offer RPMs, and that would accept queries on RPM dependencies, returning sets of RPM headers that would fulfill such dependencies, and then accepting download requests of said RPMS.
Even if we got that far, I still see problems. One of them is that of trust, that I've already discussed. The other is that of choosing which of the packages that satisfy a dependency to download and install. If there is not a central authority to label packages as say stable, unstable, testing, who gets to make the decision? And, more importantly, how about alternatives? Say a package that requires a MTA: should sendmail, postfix or something else be installed? If so, which exact version?
The way I envision a client for such a P2P system, it should present the options to the user, resolving and presenting further dependencies, leaving it up to the user to decide what RPMS are to be installed. Hardly something that can (or should) be automated.
I would recommend to use XML (namely RDF) format: the structuring would be much better, it would be under very good verification and it would not a problem to check configuration dependencies. At least it would be a foundation to create a standard for configuration dependency control.
Less is more !
This just occurred to me. What if, instead of requiring a certain file system layout in every distro, why not just require that every distro has a config file or set of environmental variables that point to the locations?
/etc or whatever, just get them to make a CONFIG variable that points to whatever folder they want to put the config files into.
So instead of forcing every distro to put config stuff in
This would of course require every software developer to rewrite their stuff to use the variables instead of the path but that wouldn't take all that much effort and it would be a hell of a lot easier than trying to force the distros to make a major change.
Would this idea work? I have only very little experience with linux but it seems like this would be a good solution.
So, does RH give you the option to install ssh with or withour X support. X support is damn useful, and if I were to install X, I'd definatly want it. But on a server, I wouldn't instal X and wouldn't want the dependancy problems. It seems a little much for RH to provide many different versions of the same software with different configure options enabled.
Maybe I'm missing your point, but my point was that I'd want software with/without different support compiled in depending upon what I install. As far as I know - that's not easy with RPM.
--
Hollywood representatives have publicly stated that skipping commercials is "stealing."
Sorry, I don't get your point...
If I didn't install X, why would I want to install a desktop...?
--
Hollywood representatives have publicly stated that skipping commercials is "stealing."
I gave up using RPMs long ago because of the dependancy problems, and nowadays always compile from source. I find this generally causes a lot less problems. The only gripe I have is that large programs can take hours to compile.
.o files, and a makefile. Installing the package does the final step in compilation- linking the object files.
My proposal is to distribute semi-compiled packages. The Distributor (i.e. Redhat) compiles the program on there machines as per normal, except they dont link it. They distribute a package containing
This would solve most dependancy problems. If I have a different version of a library with rpms, the program generally wont run. However if you you do the linking locally, the program is linked to your libs as if you compiled it yourself.
It also solves the time problem. Large packages would take no more than 20 seconds to link.
If you came up with a packaging system like this, and make it a little more flexible (Allow the user to choose install dir!!!!!), then you have a fast installation that works on pretty much any system.
I use Debian and there are two very powerfull tools for managing the software packages which I use — apt-get and dselect (see the docs about APT and dselect) but what you seem to ask for here is tasksel. With tasksel (it's run when you select the "Simple Package Selection" during the system installation process, and you can run it any time later with tasksel command). See the Debian Installation Manual: Simple Package Selection The Task Installer:
So, as you can see, you don't even have to know the names of the programs you need (not to say about what do they depand on), you just have to know what are you going to do (e.g. select Servers: SQL database, mail server, web server and Development C and C++, Fortran, etc.), great for beginners who want to play with Debian but don't exactly know where to start from. When I was first using Debian, I was using tasksel only, then after some time I started using dselect and have never used tasksel again. Now I'm using mostly apt-get and sometimes dselect.
I hope it helps.
Krótko: kady Erotomek
W pimiennictwie ma swój domek.
The problem here isn't the package manager. RPM, apt, deb all have their quirks. The problem is the laziness of software developers. And I do say laziness, because they release packages for their projects, but hardly ever distribute or even link to projects for which their work is dependent. Also there is a problem with cross project dependencies. If you're going to release your project in a package manager volume, then all the libraries that you depend upon must also be available is some form of package (not tar.gz or tgz :))
The rule to follow here is that all software should be released as packaged software, never as tar balls. That alone would solve over 95% of all software installation problems.
----------------
May we all live and die by the eternal flame
BeeazleBub
This is the MOST INSIGHTFUL comment in the whole thread! Unfortunately it's anonymous. And it has Score:0... No one will read it with 0 points, so please mod it up, thanks! After you mod parent up, you may mod me down...
The executive summary is that there needs to be a better designed tool in between the software developer of the package and the system admin who installs it. I would like to have the flexibility to setup a policy on my machine as to weither or not I'm using /usr/local/bin or /usr/bin or /packages/whatever/bin, etc. And then have the installer configure the package correctly to install it however i'd like.
One thing this would necessitate is making the installer be much less flexible to the developer than RPMs. The problem with RPMs is that they're way too flexible for the developer of the package. There needs to be a simple, inflexible API or else you're going to have a mess.
I titled it "why unix needs a registry?" just to throw some gasoline on the fire... Read it and see what I really mean (unix needs a centrally-accessable database of metadata about installed programs...)
2. Solutions presented are weak and are either worse than the perceived problem, or have weaknesses that are arguably just as bad.
How about a story line like:
The Wheel is Doomed!
Sure am glad that this got posted in lieu of something truly worth our while.
It is official; Linus Torvalds confirms: RPM is dying!!!
One more crippling bombshell hit the already beleaguered RPM community Linus Torvalds CNN confirmed that RPM market share has dropped yet again, now down to less than a fraction of 1 percent of all package managers. Coming on the heels of a recent LinuxWorld survey which plainly states that RPM has lost more market share, this news serves to reinforce what we've known all along.
You don't need to be a Kreskin to predict RPM's future. The hand writing is on the wall: RPM faces a bleak future. In fact there won't be any future at all for RPM because RPM is dying. Things are looking very bad for RPM. As many of us are already aware, RPM continues to lose market share. Red ink flows like a river of blood.
All major surveys show that RPM has steadily declined in market share. RPM is very sick and its long term survival prospects are very dim. If RPM is to survive at all it will be among academic dilettante dabblers. RPM continues to decay. Nothing short of a miracle could save it at this point in time. For all practical purposes, RPM is dead.
Ah! I had thought you were talking about binary packages. Especially since Debian doesn't have source 'packages' (just .tar.gz sources with diffs) i tend to consider packages to be binary things.
Well, if you use a package style like libc6 does, then it's easy enough. Otherwise... hmmm... ok, you got me there. Personally, i just put my patch online and expect people who want to compile to know enough to download and apply it to the standard sources ;)
--
perl -e'$_=shift;die eval' '"$^X $0\047\$_=shift;die eval\047 \047$_\047"' at -e line 1.
It's about time someone called bullshit on rpm. One of the interesting points in the article was that not all packages are created equal, thus you must find a package that works for your version of rpm, your distro, and the version of your distro you are using. However, I have found that even using rpm's from the install cd of the next version of an rpm distro will not mean the install will go through smoothly.
I'm not just talking about normally failed dependencies; that is understandable enough and can be dealt with (though the author was more than generous in his treatment of the goose chase that can be) but in fact I am talking about a situation in which you have libfoo-mdk-8.0-5.5.1 and are trying to install the rpm for libfoo-mdk-8.1-5.6.4 and it chokes, saying it requires libfoo-5.5.1 installed, or something to that effect.
When you can't even use rpms from the next version of a distro to upgrade your distro, there is a problem. Hell, even microsoft had that much working long ago. Why is the answer to getting to a new version of a distro often a fresh install? For that matter, why do many distros in their faqs for setting things up only tell how to do it in the install, as though no one is ever going to change things later?
Which of course is why I use slackware. The system is clean and relatively free of proprietary extensions to the way things are done. Most things are configurable on a slackware box in the same way most other unix boxes are. And I don't have to deal with rpm's. At first I used the slackware package system a lot, but lately I just compile most stuff from source.
Of course, this does not deal with a major cause of rpm dependency hell, which is the extremely fragmented nature of linux projects. Granted, this is building off the unix tradition of using mamny small parts to come together to a cohesive solution. However, it becomes a problem in two areas: one being the desktop user, and two being complex applications that require many of these parts. Usually the two are involved together, as with a project like Enlightenment or KDE. The problem is that when you want to install one thing, it requires 30 others. But you have to figure out where they are. Now I can do that, though it can be a headache, but what about poor Joe Sixpack and his shiny new Walmart computer with Lindows and DeerHunter installed?
In desktop systems like BeOS, OS/2, Windows, or MacOS, it is typical to encounter everything needed to run the program packaged with the program, right down to system libraries. What Windows based game written in the last 6 years did not come with some version of DirectX right on the cd? Now, granted, the windows way screwed many over, as program installers installed older libraries over newer ones and wreaked other fun havok on people's systems, and microsoft's patches gleefully broke people's programs. But, still, if we are talking about getting linux on the desktop, we shoudl be talking about learning from microsoft's mistakes and coming up with something better.
I think it helps everyone to have better package management, and definitely better dependency handling. I think apt-get and sourcerer's "spells" might be steps in the right direction, but I'm not ready to call it there yet. Oh, and I am sure lots of responses to this article will say it should be tough for newbies. But what we tend to forget, is that there really is not anything wrong with things being easier to do. In fact, saving time and trouble is supposed to be what technology is about, and putting a better tool in a skilled hand is the best thing we can do. The only problem is when we obscure the works so much that it is difficult or impossible for that skilled hand to fix the tool should it go awry, and this is of course the case with both windows and rpm, which is why I use neither if I can help it.
The syntax of UNIX config files is pretty standard
/etc/hosts? Yeah, that looks pretty much like the one used by syslog.conf, except oops you can't use spaces in the latter, it has to be tabs. Of course neither of them look much like Apache's config files, which in turn bear no resemblance at all to SAMBA's. Oh, and let's not forget what happens if you're silly enough to leave a blank line or a comment somewhere in /etc/passwd.
/etc directory on a newly installed RedHat or Solaris machine contains close to a hundred files, and damn near each of them has its own unique configuration syntax, many of which will cause total failure if you use it in the wrong file.
It is? Please enlighten me: which standard would that be, exactly? The one used by
The
The sense of accomplishment that unix geeks get from knowing how to manage this 50-car-pileup of interfaces somehow usually manages to overwhelm what should be our righteous indignation at being asked to do such a stupid thing in the first place.
You can rag on Microsoft's design choices all you like, but at least they actually attempted to solve the problem. Hell, at least they realized that there was a problem. Throwing your hands in the air and saying "let each app pick its own way" increases your job security at the cost of decreasing the likelihood that unix will win the datacenter wars.
News for Nerds. Stuff that Matters? Like hell.
It is not so much RPM that is to blame for installation problems, it is the level of consistency of package information and its use, which is a function of creator and community meticulousness not so much of the package standard. And the user interface to that could do some improvement on existing ones. I know Slashdot != Santa, but choose not to believe that now :)
/stand/sysinstall is in FreeBSD. So it'd more need an interesting project effort rather than abandoning the RPM.
.. head as a default UI skin when the UI does its job would not hurt, either :o]
A key is how to fully use all dependency and configuration info in a trivial UI, for a generic package manager from all RPM vendors and even others. There should be a globally upgradable distributed database to resolve consistency dependencies among all RPMs etc. ever published. Way too many distros today to converge.
Trying to set more rigorous standard there won't hurt but the database would be more short term solution. Compilation option data should be standardized, dynamic download location pickup, and all data needed from rpmfind etc. to figure out things for non-default-distro packages would need to be built in.
Systems like Ximian's Red Carpet are a good start to show what the UI could look like. I'd still simplify the default a bit. I used Debian dselect around -96 when it was new but moved away due to then continuous inconsistency issues. Stepping backwards to RPMs was a time saving issue tho I lost dselect benefits for some time.
InstallShield -like simplicity, reliable global dependency checking, alternative ascii UI, easy batch-mode with system- and category wide upgradability, and the sharing and parameterizable multi platform support are a must for a future RPM UI. Whatever I have considered, all pieces are not yet there. Such a front should actually handle dpkg, rpm, and whatever else there are, all simultaneously. One should be able to choose source vs binary upgrading with params setup for both, whether upgrade is for the running system or some other target (pull/nfsmount that arm/old i386 sys disk from that slow/old box and go). Verification is also important for not to make it a trojan install system. I would not mind privacy for snoopers not to know my setups.. Users should be able to upgrade consistency info in that database and kernel (driver) configuration should be made available thru it also. Generating a bootable default install CD/DVD image that would (meta)install the chosen system either from network or by local copy from stuff on the CD/DVD would be a plus. Yes, and my granny would need to be able to do some install with the UI (not necessarily the one with the right global compilation optimization params through all packages, though).. And put the same UI to be available as a standard tool for newinstall disks, like the
Yes, and a nice blonde shaking her
That's all, Santa.
That's a interesting point - however, dependencies are closely linked to what features are compiled into a program. Let's say you want to package Nautilus: it's possible to disable mozilla support at compile-time, removing the need for mozilla to be installed. But then you remove an important part of functionality. Or, you could try to split the package into speperate pieces where that is possible (nautilus/nautilus-mozilla or mozilla/mozilla-mailnews/mozilla-irc etc), but that won't always work either.
It's always a tradeoff, and there's always someone who isn't satisfied. Say you put everything realted to Gnome in one package - very easy to install, and probably doesn't have a lot of external dependencies except obvious ones like X and glibc. But then someone shouts "Bloat!", because he or she doesn't want to have Evolution installed jut to run Xchat. On the other hand, if you look at Gnome now, it's at least 10 different packages on top of X that you need to install (and run) Xchat. Which is better?
I short, it's impossible to please everyone at the same time. If you're not satisfied with the way someone else has done the job for you, do it yourself.
Hello, my name is Robert Lerner, and I pronounce Lernux as "99% cpu"
Thought some of you might like to know:
Branden has just released the first -pre version of the XFree86 4.2 Debian packages on his personal site, and on several mirrors. (NOT official debs yet; NOT in sid yet)
See the anouncement and obligitory flame war at:
http://debianplanet.org/article.php?sid=696
Happy breakage!
~.~
I'm a peripheral visionary.
Actually, the X forwarding stuff isn't a compile time option. It won't work unless you have X installed, of course, but it doesn't break it if you don't.
./configure && make && make install!".
The packages that have options that would cause dependencies (e.g. emacs with X11 support) are in fact often split into different pacakges - emacs-nox and emacs-X11, vim-common/enhanced and vim-X11. Other ones take advantage of software that has modules, such as apache and perl. And a large number of other packages are compiled with optional features enabled, but not turned on in the config files.
Big dependencies (e.g. X, Python, Perl) *are* seperated out into their own packages, and in most cases other features are turned on by default. And once you start looking at desktop level software, configuration is usually done within the application, not compile time. But even when that's not the case, it is often provided with plugins its easy to package on their own (look at GStreamer, the multimedia framework - each codec that has an external dependancy is split out into a seperate RPM so you can install only those features that you actually need).
My main point is that most people *don't* do customization on their software. Remember, the mantra of source code advocates is "but compiling is easy, it's just
I can see the appeal of something that automatically configures itself based on what you have installed, even if I see it being of limited utility. And I can see some issues with it, such as the gentleman who pointed out that in Gentoo, if you compile with a library installed, then remove that library, it will silently break the application.
As for difficulty in custom compiling RPMS, it's really not nearly as difficult as people make it out to be. On a lot of packages, if you do a rpm --rebuild on a SRPM, it runs through a straight configure that detects what libraries are installed, and the find-requires script will write your new RPM with all the proper dependencies.
And if you need to change an implicitely specified option, you can install the source rpm, change the "./configure" line in the spec file, and rpm -ba it.
But most of the time this really doesn't buy you much. I run about 60 Red Hat machines and the only custom RPMs we need is software that was written or modified in house, and the kernel, since there was a particular issue that we needed to patch away (a two line change to the spec file).
Matt
It's just as st000p1d as the DLL crap with Windoze. You might have an excuse with proprietary software that's kit-bashed from different sources or of which you may want to update or patch a "feature", but with software of which you have the source, there is NO EXCUSE for that dependency crap.
At least, that's one thing most Macintrash programs have right: no goddam fucking library/DLL dependencies. Everything is in one binary file!
With the big disks we have nowadays and the high bandwidth, there is no reason why you should not be able to include the whole fucking shebang with the application, and keep it isolated (to prevent it from breaking other programs) on your system while you compile it.
(Reposted, account being moderated into oblivion)
woot! This is my first 666th post.
I haven't suffered that much of the dependency hell of RPM maybe I don't try the new bleedin' app that comes out. I have tried Gentoo Linux but unfortunately I use an Old 200 mhz Pentium w/mmx. I have had if for 5 years and whereas I've tried to get gentoo to load on it it just won't but my Red Hat installation just continues to purr along without a problem.
Maybe, I'm the odd one. I've packed newest graphics card, the newest ethernet card, new monitors, but USB 2.0, a logictech wheelman mouse, more memory (256mb, the motherboard can't go any higher), the latest harddive and the damn thing keeps running and not only that it running so damn smoothly. I've installed new programs and usually get the source file rather than RPM but when there has been no source just a binary RPM it never has failed me...
I'd love to use Gentoo and Sorcer but they just don't work for my old workhorse and Red Hat does....
Later
Save Pangaea!! Stop Continental Drift!!
Many fine point have been raised, but my favorite RPM nitpick is found in Mozilla.
For awhile a not-so-fun package conflict existed when Ximian (a fine company) decided to grab a library out of Mozilla (a fine project) and reuse the code in another package (a fine idea).
Unfortunately, this led to packaging a library in it's own rpm (a good idea), but this ONE FILE INCONSISTENCY created all sorts of minor annoyances every time Mozilla hit another milestone (and who doesn't want the bugfixes?)
True, the inconsistencys were minor, and it wasn't difficult to overcome them (after reading Maximum-RPM, which was what I both should have done in the first place and what I recommend to anyone using an RPM based distro) but I felt that a bit of communication between the two packagers could have eliminated this problem.
Then I thought about it some more... How would a project developing something with reusable code (like Mozilla) know that someone else was repackaging it for their needs, and why would they change their packaging model just to satisfy the installation of another product without the need to install the product itself? This does not make sense.
It is easy to want something our way, to want it our way automatically, and to not want to know a thing about it.
I use RPMS when they are sufficient.
If RPMS don't do the job (a security patch is needed, etc.) I just uninstall the RPM and compile.
Likewise, sometimes RPMS are lacking in features available only if you compile from source (PHP is a good example).
Just save your source directory somewhere so you can find everything when it is time to remove it... or upgrade.
l8,
AC
The problem with the registry is that it is a single point of failure that is also prone to failure. /etc is not prone to failure at all. Making trivial system changes, non-trivial meaning altering something not part of the boot sequence, can't fuck up your system that badly. With the registry, a simple crash or power failure can toast your system.
Further, your "multiple points of failure" line is complete bullshit. The files in /etc, being multiple files, isn't in any way meaningful at all, except modifying one can't corrupt another, so you're actually completely backasswards in your logic.
Sticking feathers up your butt does not make you a chicken - Tyler Durden
Great! I will try it. I didn't know it existed.
Aptitude looks to have learned some of the lessons of dselect and provides a decent text based package management solution that isn't so confusing. The one drawback with aptitude is that it can't be used for single package installs (unless your system is completely up to date), but then again, that's what "apt-get" is for.