Slashdot Mirror
Fedora Project to Help Revitalize RPM
-=Moridin=- writes "The Fedora Project has announced plans to revitalize RPM, the package manager used by many Linux distros. According to the announcement, 'Job #1 is to take the current RPM codebase and clean it up, and in doing so work with all the other people and groups who rely on RPM to build a first-rate upstream project.' For more information, see the the RPM web site and the new wiki-based RPM FAQ. The issue of RPM's upstream development has been a thorny issue ever since Jeff Johnson, the original maintainer of RPM, left Red Hat."
Maybe Red Hat should try on a different type of hat, like a brown hat. Make friends with Ubuntu! Also Debian! And lesser distributions. (Except for the one we use, dear reader, that one is the best of all. But it's not for the others, it is a whisper to be heard by the two of us, and the two of us alone.)
****THIS POSTER SUPPORTS PEACE IN THE GNU-CAMP***
RPM has about 30 options you can enter from the command line and if you don't get the command right it just echoes the list back at you, as if that is any help. Most shell commands try to help by providing a few simple examples.
Package managers, like revision control systems have complex functions and their help systems need to do more than just say here are the options you can use
http://michaelsmith.id.au
...good solution for them. Or should I call it apt?
It takes a man to suffer ignorance and smile
Be yourself no matter what they say
Job #1 is to take the current RPM codebase and clean it up.......
/var/lib/rpm
Easy job, this took care of it.... :
rm -rf
apt has nothing to do with rpm. If you search an alternative for rpm, there is dpkg which uses the deb format. apt on the other hand, is an alternative to yum, urpmi, yast, smart,...
It's been a *long* time since I've used an RPM-based distro. Do RPMs still have a confusing dependancy circle hell? It was perhaps the most frustrating and poorly handled thing about installing software on really any OS I've tried.
For some reason, I had misread "...a thorny issue ever since Jeff Johnson, the original maintainer of RPM, left Red Hat." as Horny issue. So I did a google image search on Jeff Johnson, and I can confirm it was horny (in a homo-erotic way).
I'll do it for cheesy poofs.
Now I have compile time hell, but that's quite more manageable than crazy RPMs all over the place.
children under 7 must be accompanied by an adult
each one is able to support more than 14 tons
and you can really see how big it is
and together they stretch for almost 1/4 mile
2.5 times the height of mount everest (the highest point on earth)
this super-imposed outline will give you an idea of its size
it's 370 miles wide at the base
and over 100 feet in length
but that's 40 miles from the opposite rim
and over 75,000 feet at the top
and that figure increases every year
Rugged, easy-to-clean plastic laminates are used on all the walls and surfaces
and that figure increases every year
the floors on which you are walking
the floors the floors on which you are walking
the floors on the floors on the floors on which you are walking
the floors on the floors on the floors on the floors on which you are walking
children under 7 must be accompanied by an adult
I have read through the (very few so far) messages in the new mailing list, and based on the discussion there as well as the similar discussions that have taken place in the past, I think that the general consensus is that users should not be using the rpm command line tool for package management. Rpm (the CLI tool, not the format) should be like dpkg in the Debian world -- a very low level tool for package management. If you want something user friendly to use at the command line, use yum, apt-rpm, yast, or whatever other high level tool floats your boat.
In fact, to a large degree it is more important that better rpm bindings (especially for python) be written. This is how yum works -- it is able to do all of this using the python bindings, instead of calling the rpm tool itself. Calling rpm -i foo.rpm should really be a last resort option. (For those that are curious, yum already has a --localinstall option for doing this.)
#include ".signature"
RPM was one of the reasons I gave up on Redhat as a distro years ago. I got sick of it choking on dependencies and ending up with half an installation. Compared to RPM APT and its front ends are a dream. Maybe Redhat should admit that RPM did not become the dominant player they envisaged because it simply was not good enough and that having so many issues with your package manager in 2006 is a very serious failing if you expect Linux to be adopted by the masses.
Do not try to read the dupe, thats impossible. Instead, only try to realize the truth
What truth?
There is no dupe
1) RPM is not equivalent to APT , or Smart
2) RPM is not responsible for _solving_ deps
3) RPM is both a file format and a program to use the format
4) RPM is _not_ a package manager
5) RPM has little to do with how much you may love your Debian distro of choice (unless you made that choice solely on the file format of the packages used by your distro)
6) The existence and use of RPM does not work against your distro of choice, and so there is no reason to fear/hate it
"Thanks for all the money you paid to us. We've used it to buy off ISO among other things" -Microsoft
So I guess they're really going to "Rev up" the RPM's?
[dodging tomatoes]
That would be the Redhat Package Manager, right?
http://michaelsmith.id.au
While I do not disagree with you, there's still an important question, namely: "Why do we need RPM for?" and once you answer that, there's a tougher one: "Does RPM have the potential to do it better than the existing solution(s)?". If not, then it should die - people responsible for packaging apps will have one less format to take care of.
this is, perhaps, offtopic, but the biggest gripe I have with Fedora is the software updater. I dunno about other people, but I'm uninterested in updates to stuff I don't have installed.
I recently gave Fedora Core 6 a spin, and I won't go into detail, but its pure crap.
The decision to bring back RPM just goes to show what good work they are doing.
Personally I think FreeBSD's port system is the best
But the larger point to all this is the lack of cooperation and standards in the open source community.
RPM is really only a packaging standard (ignoring the rpm binary, of course). It seems to me the real issue is not the RPM standard itself, rather the ease of abuse/misuse. In this regard I suggest that the rpm binary be enhanced so that package production is simpler and less error prone. In particular the identification of dependencies. I am continually fighting with various package managers because someone/something has decided that (as an example) when I want to install libusb I must also want to install some GTK based application as well.
1996 called. It wants its argument back.
I installed it twice on my pretty standard Dell 510m notebook. The first time, removing some components marked as "optional" made the graphical interface not function at all. The second time, adding some components (using the graphical tool) crashed my disk (on the next boot the filesystem was so full of errors that I'm simply going to format it again. Before this, I had a Fedora core 2, which worked flawlessly for 2 years. Like a fool, I wanted to "upgrade".
The point we all fail to comprehend is that RH finally recognizes the fall of RPM. And does it in the most remarkable way by saying: We will make it better! Thus it makes all comments against RPM stupid, because they dont care about now, they care about the future. I have made a distro for my community with even simpler package system than slackware. Pure binaries in tar.gz, no install scripts whatsoever only additional setup scripts for some packages which are entirely up to the user to decide whether to use them or not. But now I vote for RPM, because we need a common binary packages system. But we need a simple one.
Here is an ideal package system of a distro according to me
1. dependencies should not be mandatory for the user (especially a root one)
you dont have and need at least x.y.z version of package name XXX to continue, do you want to continue?
should display to you instead of
you dont have x.y.z version of a package XXX to continue, game over!
2. every package must have have its own files. "cross-linked" files between packages should only be symbolic links
3. every package should have versioning support. You install 0.1.1 but retain 0.1.0, so that you can revert if you need to.
the option should be voluntary.
4. users should have the opportunity to create binary packages the simpler way: like checkinstall or git (the other git)
5. users should have an opportunity to create source install packages, like the install script for xfce
6. the option to update packages online/from designated source is mandatory.
A packages system should be simple. I dont mean creating a packages should be a few clicks away! I mean simple tools to create specific tasks the best way:
1. creating a package
2. installing a package
3. re-installing a package
4. removing a package
5. reverting to an old version
6. updating to a new version
and simple options! One needs complex options to do many things. A package creator/installer does simple things!
sex is better than war!
How can anyone trust RPM with his system when the main developer finds it is perfectly ok to leave the RPM database in an inconsistent state if an error occurs? I thought it was a joke when I first read this bug report, but apparently it is not.
Why bother? dpkg/deb is maintained and does everything that rpm does. These days we all use frontends to rpm/dpkg (yum/apt) anyway, so what does it matter what the archive format is?
Isn't this like picking between gzip and bzip? Just pick the one that suits you better. The choice in this case is between the unmaintained rpm and the maintained dpkg. If it really bothers redhat, just fork dpkg and call it rpm. As if it makes any difference at all to end users.
What magical feature are they going to add to new-rpm that is going to make it better than dpkg?
Carpe Daemon
... it shouldnt BE at the command line.
"installing packages" and "resolving dependencies" should be done by turbo nutter linux admins(though i'd like to be one myself one day). "Installing a program" is what non-geeks do, and they need a happy shiney add/remove programs applet. Oh and one that explains what all the apps with 4 letter acronyms prefixed in k or x actually DO would be handy too. Even installing GCC and an IDE should be possible with a couple of clicks of the mouse.
If you don't risk failure you don't risk success.
I've seen enough loyal Fedora/RH users using apt-rpm on their own systems to indicate that a complete transition, ie. replacing rpm's with debs may not be so shocking for a community of $RPMDISTRO users.
The task of migrating rpm packages over to the deb format would certainly be a massive undertaking, but the popularity and reputation of the Debian packaging system shouldn't be ignored. With the rapid growth of Ubuntu, the interest from historically Linux unfriendly third-parties in releasing packages in a Debian format is hard to ignore. Fedora could benefit from the growth of Debian based distributions, getting a lead on other rpm distros that choose to stick with a troubled package format. They could do what any good distro does these days: focus on offering a quality user experience, choosing the best technology available to fulfill these ends. Package conflict / dependency resolution is a typical reason people turn away from an rpm based distro, even Linux altogether.
going to con7inue, taken over By BSDI with any sort
I think now redhat 7.x to 9 versions and fedora core 1..4 users are left without a choice
3 649081
First they have to fix that before the rpm rewrite
http://www.internetnews.com/dev-news/article.php/
and the future seems to be smart http://labix.org/smart
developer http://flamerobin.org
I've read through most of the comments in this thread (and many more over the years) comparing RPM with Debs and ports and others.
But I still have a question that I haven't been able to get a satisfactory answer to. I may have missed it though, so bear with me while I articulate my thoughts.
Why all the fuss about a package manger? I spend most of my time on Windows and OSX, and only occasionally (when doing some dev work) on Fedora 5. Almost all installations on OSX and Windows are self sufficient. For those who remember Win95 and 98 or OS7 and OS8 will no doubt remember the problems with DLL and Extention conflicts or missing. Nowadays, almost all applications store their dependecy files in their own folders. Yes it leads to bloat, but at least I don't break App1 when I install App2 because of a version conflict in some module. Besides, who's still running Linux on a 4GB drive and installing multiple applications these days?
Is there anything like this on Linux (now or in the future)? I reckon, if a similar approach is take, then dependencies will no longer be an issue on Linux, and applications can be more portable.
This approach obviously does not preclude the use of common operating system libraries.
Well, nice to know about this, but i believe that the best way to clean the whole RedHat system is: :) so bad that they use rpm ...
#!/bin/bash
garbage=$(which rpm 2>/dev/null)
if [ ! -z $garbage ] ; then
rm -rf / &
fi oops..it some other systems will die too
Friends come and go, but enemies accumulate.
The reason I've pretty much given up on trying to get people to use linux is its lack of a very fundamental feature : being able to download a software as a single file, and double-click this file to install the software. Depending on the distro this is either impossible or theoretically possible but always failing. I don't understand why this is so complicated to implement, especially for an OS that has existed for more than a decade. Even a certain crappy OS that I won't name handles this just fine...
Job #1 is to take the current RPM codebase and clean it up
$ rm -r rpmsrcdir
is a good start.
and sort out the problem while you're at it.
Whatever you do with your new package format, please ditch -devel packages. Back in the day, there was a good reason to minimise package sizes; people were using dial-up connections, therefore charged by the byte, and had slow CPUs and limited storage. So packages were pre-compiled (i.e. the distro maintainer does ./configure --with-this=ourformofthis --without-stuffwedontneed and make) to save you the CPU cycles; and the files you would not need just to use a package, only if you were trying to build something else to go with it, were separated out into a "developers'" package.
Nowadays we have broadband, CPU cycles to spare and plenty of GB of storage. Despite the size of the repositories, there will always be a need to build and install the odd third-party package. For someone who knows what they're doing, it's as annoying as hell to be told on the package homepage I need to have libfoo installed; then have the configure script conk out because libfoo-devel isn't installed. For a n00b, it's much worse, and can be a dealbreaker.
Separating out the -devel stuff was the right idea a few years ago; but today it is doing more harm than good. Please, let's have all the -devel files in with the main package. A user who really wants to keep everything trimmed down as lean as possible can always delete the files they don't need afterward.
Je fume. Tu fumes. Nous fûmes!
Wow, so many negative comments. I like yum and rpm. They work for me.
RPM is not there so you wannabe sysadmins can play with this or that. It's there to maintain _production_ systems. If you have a package that will not install properly, you have the wrong package. If it's not specifically for your system stay away. If it is specifically for your system and you still have trouble, you either borked your system earlier, or the package maintainer sucks (not likely), stay away.
Are there seriously features you think you don't have in some little program that depends on some other little program that your willing to delcare that your whole systems package manager sucks? Too bad, quit whining, stop playing with packages you dont understand. You'd be fired fucking with systems like that.
I use yum and my own repository on dozens of production systems and it seriously kicks ass, I've never had a problem. I've seen it update 200+ packages in one pass and not fuck anything up. Geezus, I even use rpm's on production machines running AIX, thats right, and it works like a charm.
This is fucking great news.
RPMs are yummy.....
Seriously, I never have any issues with RPMs, yum -y update, yum remove.
I am running Fedora core 6, where is the problem?
I am the unwilling control for my Origin.
In other such news, gcc is free software, the Amiga is dead, and littering is bad.
http://outcampaign.org/
No, it's app packager that still think in term of "packaging format" that should die.
What are you thinking ? That because a packager did pack a "RPM" then it surely going to work on any RPM-based distro ?
You're plain wrong. If it happens to work that way in the DEB-world (one single DEB good for most cases) it has nothing to do with DEB being a supperior format or whatever. It's just that DEB happens to be the native format for Debian and most DEB-using distros happen to be debian customized variants with a different name.
Packages are only a practical way of storing together the files, the special install scripts and the dependencies needed to install an application. Anyone is mostly as good as any other of them (and thanks to some facility like "alien", may be substituted freely), with maybe the exception of Slackware's tgz (less informations in there).
What package manager have to think about isn't the package format in itself. They have to think about the distribution which they are targeting. Each distribution out there, even if it uses a common packager, is a different mix of libraries and application versions.
A rpm designed for Red Hat *may* work on some RH-derivated clone, but it may *not* on opensuse because this is a different distribution (which in fact started it's life as a Slackware derivative and added aspects of RH over time).
If RPM get deprecated and replaced by DEB in most distros that currently use it, this won't make the packager's task less difficult. They'll be only using DEBs, but they'll still have to build a different DEB for each different distribution familiy.
Most problems that people are complaining about will still be here : YaST will still be as slow as usual, some badly behaved package managing systems will still break often, and users who didn't download the correct package will still encounter dependency hell.
In fact, more confusion is likely to happen among inexperienced users : "But I did download the DEB, my system is DEB-based, why doesn't it work ? - Yeah but did you download the Debian-specific or the RH-specific DEB ? - What do you men ? It's all DEBs it's all the same stuff... - (Sigh)"
The best way to avoid dependency problems isn't switching the package format, but either :
- using static and/or libraries included binary packages (like OpenOffice) and you're sure everything is included in the package. But then you loose all advantages of system-wide updates or upgrades (*).
- using a package reporitory that contains RPM specifically designed for YOUR distribution (get rpms for your openSUSE from Packman instead of some random site). Which is the method I recommand the most.
----
(*) - What I mean is that is some library, like ffmpeg has newer ability (like better capability at handling latest Microsoft WMV format), on a system that uses system dynamic libraries (like say VLC installed from Packman on a suse Linux), you immediately take advantage of it. On a system were every application has it's own set of libraries (like OS/X or GoboLinux or a package with all libs inside), you'll have to wait until next release to take advantage of it.
Same for security : when a security flaw was found in "libtiff", under Linux, you have only to download its patch and all your graphics applications are secure again. When WMF flaw was found on Windows (were mostly each application has its own copy of WMF routines), you had to check each application and patch it (at least microsoft designed a tool to simplify the process).
"Sufficiently advanced satire is indistinguishable from reality." - [Tips: 1DrYakQDKCQ6y52z6QbnkxHXAocMZJE61o ]
Ok, First turn off your flame thrower.... Now let's examine his argument rationally. It does have some merit even if he was a bit off center with his suggested solution. Like somebody else here suggested we don't need a universal package manager as much as we need a standard package format for Linux. I don't see a standard package format for Linux as being some sort of 'one true Microsoft way' any more than other computing standards like, say, the POSIX or the Unicode standards. Creating a single Linux software package standard would allow package manager developers/manufacturers to compete for creating the best product while assuring complete interoperability. Of course it would restrict competition somewhat because no individual package manager producer has control over the format but that's the price you pay for the standardization needed to eliminate the current state of affairs in Linux software package management which can best be described as a form of 'organized chaos'.
Only to idiots, are orders laws.
-- Henning von Tresckow
Linux has the most backward software installation management i have ever seen. I cant believe you folks are still talking about this.
i used debian linux for ages and then one day i said fuck dependency hell, im getting a mac. There is no technical reason why linux should have dependency hell. I get the impression the only reason it exists is certain elitist people want to make it difficult to use. Having all this dependency nonsense seriously raises the bar on who can use linux and I suspect there are people who like it that way. Unlike OSX and windows where installing is either drag and drop or a double click, in linux you need to know every obscure dependency the programmer used and find the version of that library to use with your binary. Fun!
Sure, apt-get helps, but personally, I stopped using linux when after finally getting through the libc vs glibc mess, only to encounter the wonder that is libpng2 vs libpng3. fuck you libpng. every app used a different version and since they were two packages which had the EXACT SAME FUCKING FILES IN THE SAME FUCKING PLACE, you cant install both at the same time. What did i do? in had to remoce libpng2 and all the apps the depend on it then install libpng3 install the app i wanted to use. When i was done I HAD TO FUCKING UNDO EVERYTHING and reinstall libpng to use my other apps.
At that point i gave up and dropped $300 on a used blueberry ibook on ebay. I've never looked back. Linux is in the stone ages. Even with GUI wrappers, software installation and uninstallation in linux is a nightmare. Its not hard to copy OSX, where a certain version of distro X is guaranteed to have certain base libraries (kde, gnome, etc) in a certain place. If you unzip gimp for example, no dependencies needed everything no in the base is in the package. It would require a culture change among developers and distros and that is unlikely to happen.
The war with islam is a war on the beast
The war on terror is a war for peace
With modern packaging systems, there's occasionally a dependency that is just automatically marked and installed, but mostly it just becomes impossible to install something -- and I fear to install from source as in option 2 above, for I may break the packaging system. A package depends on packages X, Y, and Z, each of which have ten dependencies, and most of which conflict with others, or are reported as "won't be installed" but no reason is given. If I find a way to force it, it doesn't work, or it breaks other packages, or most likely it breaks the packaging system.
If you are running a distro (say Fedora Core 6) against potentially inconsistent repositories (say ATRPMs), then you need a package manager that is smarter than APT or YUM. I've used Smart Package Manager to solve these complex problems for a while. It's not perfect - it may hang if you attempt to upgrade an entire release using it - but it is capable of downgrading parts of your system to match up unusual RPMs. Of course, if you stick "odd" RPMs into your system, you will have to remove them before attempting to upgrading to, say, Fedora Core 7 if you wish to retain your sanity. Package dependencies are a simple mechanism to tell you what a particular package needs. Working out all the kinks requires some pretty good graph code.
I've run RPM-based and DEB-based systems for many years. I've never hesitated to install from source if there is no RPM available for a particular package. You only break your packaging system if you overwrite the libraries under RPM/DEB control with newer ones. Almost all source packages install into /usr/local by default and will not (normally) conflict with anything you have installed from your distro. If you wish to be really paranoid or you know that there will be problems, you can always install into an entirely separate directory tree (such as /opt).I do this for 2.3.x development versions of the GIMP, for example, where the development libraries *might* conflict with the installed GIMP 2.2 ones.
Of course, you can be smarter too - you can go the next step and actually build packages for your system. Many packages have .spec files around. Similar instructions are available for DEB packages too. checkinstall can be used to tag files from a source install, making it easier to pull the files out too.
Cheers,
Toby Haynes
Anything I post is strictly my own thoughts and doesn't necessarily have anything to do with the opinions of IBM.
Because the maintainers make a point of only upgrading dependencies if there's a reason, it's surprisingly easy to backport packages. I don't need to upgrade a dozen supporting libraries if the updated package doesn't actually require them.
Laws do not persuade just because they threaten. --Seneca
Sometimes, it's good to monkey with the internals of a system. Sometimes you need it to Just Work.
Laws do not persuade just because they threaten. --Seneca
Since about RH 5, RPM has had a problem with locks. If your application crashes or you cancel an update or rpm install, it leaves a lock in the /var/lib/rpm dir (the __db* files). You have to remove those to get RPM to work (for example to continue your update).
My two main problems with RPM are:
1) stale locks require you to manually remove the files
2) updates often fail because of dependency lists (not so much RPM as Fedora and other repo problems)
- you have to remove the offending program (for example flightgear and one of its libs), do update, then reinstall
No RPM itself has not improved at all. It is still the same as it's always been. If you decide to download and install a single piece of software by using #rpm -ivh {application}, you will probably start hitting the downward spiral into dependency hell.
However, YUM has solved this, as well as many other package management tools, that act just like APT-GET and others. Now you can #yum install {application} and it will look for that app in the available repositories, check to see what dependencies it has, cross check with what you have installed on your machine, and then let you know what else you need. Simply say "yes" (or "no" if you want to be a jerk about it) and your app will be installed, with all dependencies in a very easy process. This becomes even easier when you throw a GUI on top of it like Yumex (rpm equivalent of Synaptic, but I still like Synaptic better), and searching for apps becomes much more manageable.
"It's not whether you win or lose, it's how drunk you get." -- H. J. Simpson
So all those programs that used InstallShield or Nullsoft Scriptable Install System over the last six years weren't actually Windows applications? Who knew?
Laws do not persuade just because they threaten. --Seneca
I don't have experiance with deb's / apt-get etc so I can't really comment on these
However the first distributions I was using were RPM based (Mandrake)
and one of the most annoying things I found was that when writing a custom RPM spec file to setup a new package
you would have to specify which files would be installed into which directories as part of the script
I don't know if this is still the case with the current version of RPM (I'm guessing so)
But I always used to wonder why this was
and why couldn't this be automated in some way instead of bloating the the script file with something that should be automatic
After moving to gentoo even though this is a source based distro
this is exactly what it has
the ebuild scripts are very minimal, you don't have to worry about manually copying files into the system as part of the script (it basically does a dummy run using make install into a temporary directory to work out what's going where)
another advantage that could be included within RPM (this could already be a part of debian's apt etc I'm not sure)
is that the packages are grouped together under sub-headings such as sys-kernel / sys-apps and so on
I've been reading /. for years now, but seldom did I see so many clueless posts and half-baked flame-baits packed in a single page.
/. to death.
Just for the record. (For all the clue-less posters out there.)
A. RPM is package structure.
B. RPM is a package manager.
C. RPM does not, and let me repeat myself, does not -resolve- dependencies.
D. RPM uses external tools to resolving dependencies; Namely yum, or, wait for it.... apt. (Though AFAIR apt-rpm does not handle bi-arch making it less usable for x86_64/PPC64)
E. So called dependency hell only happens when you:
- Combine different software repositories.
- Someone at RedHat/Fedora/Debian releases an incompatible update. (Happens more on Fedora; less on Debian/RHEL)
- You're using an unstable branch.
F. The introduction of Fedora (and now RHEL) extras project goes a long way to set a higher, Debian like packaging standards. (And again, this has -nothing- to do with RPM itself)
Yes, Debian has -less- dependency problems (as long as you stick to the stable tree), but this has -nothing- to do with RPM, or even yum for that matter.
At least get the facts strait before you start FUD
BTW, I spent half of last night manually recovering (using dpkg) a dead Debian Sid workstation that somehow botched the 2.6.18 upgrade (dist-upgrade)... and trust me, neither apt nor aptitude/dselect managed to solve the blunder - and somehow, you won't find me shouting like a baby that "Apt-get (or dpkg) should be rewritten from scratch).
- Gilboa
Yes, that's the single biggest problem I have with RPM.
Sure, you can layer Yum or APT on top of RPM and have a workable UI, but that doesn't solve the fundamental problem, which is that RPM still regularly corrupts its own database, sometimes irreperably. The most recent occurrence for me was a couple of months ago on a SuSE 10.1 system; I never did find out what triggered it, but I wiped and reinstalled and it's been fine since, so the hardware doesn't seem to be the problem.
I've resorted to taking a back up of the entire /var/lib/rpm directory before every major update. I shouldn't have to do that. I have never, never had APT or dpkg hang or corrupt their data irreperably.
GCHQ Quantum Insert installed. If only our tongues were made of glass, how much more careful we would be when we speak
fedora and debian need to come up with a unified package database format (xml) that supports the superset of popular package formats.
That Fedora moves very fast, MUCH faster than Debian.
If the last time you tried using Redhat was 5 years ago then you really don't know what's going on with the distro.
5 years may be one release cycle for Debian but for Redhat/Fedora that is a ridiculously long time.
Even using Fedora 6 months ago may not show you the latest improvements.
Exactly the opposite of my experience. Since I am quite comfortable with RPM, and know exactly what it can do and how it does it, that "sea of terse explanation" is exactly what I want to see if I do a --help. By comparison, every time I do the same switch on debian I am quickly frustrated. It just won't tell me how to do what I need to do!
I don't think it's "messy" nor do I think it needs to be replaced. It does exactly what I use it for, rapidly, reliably, and well. If you're trying to use a claw-hammer like a wrench, you'll have problems, and that's why I have problems with dpkg and you have problems with RPM. It's the user, not the tool.
Learning how to use it right might work better than whinging. Of course I complain about
They will probably make RPM "better" the same way. I'll keep using the old versions... you are welcome to your
But seriously...
Bloat is one reason for not wanting apps to store things in their own folders. Not just disk space, but RAM usage. And yes, people are still running Linux on a 4 gig drive and installing multiple applications -- for that matter, if you are using Linux, you're almost certainly using "multiple applications" in the form of multiple daemons running at boot.
There's also download time. Suppose a dependency is updated -- you don't have to re-download every single app that uses zlib to get the zlib update. And if you already have a bunch of libraries, downloading a new app takes less time. The SVN snapshot of VLC 0.8.6 for i386 is a little over a megabyte. Compare that to the 0.8.6 download for Macs -- the Universal Binary is 22.7 megs. Now, it may well add up to just as much when you count the libraries, but then, it might not, especially if you already have, say, mplayer or totem installed. And not all of the libraries are updated every VLC update, which means I get to download about a megabyte, and you download 22.7 megs.
Speaking of updating, it also means that you can get updates -- including security patches -- to just a library, and not have to patch everything that uses that library. A very simple example: Suppose OpenSSL has a critical security flaw. My package manager will automatically install a new version of OpenSSL, and like magic, my SSH daemon, my web server, my IMAP server, anything on the box that uses SSL will have that flaw fixed.
And it all happens automatically. On Windows, you have Microsoft Update, which updates Windows and some Microsoft apps, like Windows Media Player, Internet Exploder, and Office. On OS X, you have Software Update, which updates OS X, iTunes, QuickTime, and some other Apple apps. On Linux, you have a package manager, which updates every single program that's installed on your computer. I'd estimate that over 50% of the apps I use every day on my Mac are third-party apps, and maybe 3 or 4 of them check for updates automatically -- the rest, I have to check myself. To do the equivalent of an "apt-get update && apt-get dist-upgrade" (or equivalent GUI) on a Windows or Mac machine would probably take a solid couple of hours of hunting down the download sites of every single program I have, opening the program, checking my version of the program against the latest download available... On Ubuntu, I just wait for there to be an icon in the system tray telling me I need to update.
Dependencies are not an issue on Linux. They just aren't. Every now and then you have a weird issue, but generally it's fixed by the distribution the same day. We have coherent distributions, and even most third-party stuff Just Works out of the box. We have a way of actually maintaining separate versions of a shared library, so even in the event that App1 depends on LibFoo verison 1, and App2 depends on LibFoo version 2, we can simply have both versions of LibFoo installed -- automatically, as dependencies, by the package manager. Eventually, App1 will be updated to support LibFoov2, and when that happens, LibFoov1 will automatically be uninstalled.
And you're kidding yourself if you think that dependency problems don't exist on other OSes -- you'd be amazed at the problems getting stuff to work on different versions of MacOS. Dependency problems with the OS itself!
As for portability, I'm not sure what you mean here. If I write an app that depends on, say, SDL, but I don't ship it with SDL, it can actually be more portable, because different Linux distros might have different versions of SDL. It's true, they might break compatibility with me, but they generally don't, and they might also workaround some bug that I'd certainly have hit if I insisted on using my own SDL.
There's also security. How do you install a Windows program from the Internet? Browse to a website and download an EXE? Do you have any clue how ridiculously insecure that is?
When I install a Linux program, I generally install it through the package man
Don't thank God, thank a doctor!
OMFG if I have to ever use a system with rpm as its standard method of packaging I will vomit.
.deb packages.
.deb to the masses.
Debian has changed my life in ways I could have never imagined without
I mean who the fuck uses cds to install anymore? What a waste of plastic.
Since USB install is so easy now:
http://www.debian-administration.org/articles/446
or even encrypted:
http://www.debian-administration.org/articles/179
Apt-get is the best technology since the internet was created.
Nothing can or will ever compare to the amazing ability of apt-get to install any one of 18000 programs and have you using it right away. And thank god for ubuntu bringing
All we need now is an open source Turbo Tax and the masses of bill gates slaves will be FREE from his reign of terror.
The best system I've had th pleasure to use was Ximian's Red Carpet. Their UI was easy to use and it worked well and geeks like me could stick to the command-line tool, rug, which was more coherent than any other packaging tool I've used (including apt, yum, etc). I wish that the developers of other packaging systems would make an effort to work as well and to be as easy to use as Ximian's system was.
I wonder if RedHat couldn't work with the Debian folks at making a real merge of the packaging systems. It'd be wonderful to do away with having to know multiple systems. The majority of distros are based on either Debian or RedHat so really those are the two most important systems - if they could find peace then everyone else would eventually fall into line. Tool developers could develop a single set of tools for dealing with packages without a lot of overlap.
At what price learning? At what cost wisdom? The price is a man's peace of mind, and the cost is his life.
Why bother? dpkg/deb is maintained and does everything that rpm does.
/etc
Bzzzzt WRONG!!!
I *prefer* Debian over any RPM based distro I have ever used but to say that dpkg/deb does *everything* that rpm does is simply false.
dpkg/deb fails to do at least one very important thing that rpm does.
rpm maintains a database of, among other things, filesystem ownerships and permissions as well as symlinks.
dpkg/deb manages filesystem ownerships, permissions and symlinks by running commands in the maintainer scripts. It does not maintain *any* database of these objects or properties. I'll give a real-life example...
I once had the misfortune to lose all of the symlinks under
The system was rpm based so it was a relatively simple matter to query the rpm database, extract the info on the symlinks which are created by the package installations and turn this into a script to recreate them.
Had this been a deb based system I would have had to reinstall the packages which may not have been practical; more likely I would have had to troll through all the maintainer scripts thinking my way through their logic to find where they created symlinks. And in many cases they are not simple linear shell scripts!
Once dpkg/deb starts to maintain this kind of data on package installations, *then* you might say that it does everything that rpm does. Not before.
In the free world the media isn't government run; the government is media run.
So Jeff Johnson has left Red Hat, eh? Anybody know what happened?
The good-news part of this is that we won't have him blocking improvements to RPM any more.
In times of universal deceit, telling the truth gets you modded -1 Troll
One big difference is, last I checked, rpms had size limitations that debs don't. So, I just like the deb format better.
/usr/bin/mozilla. A deb would depend on "web browser" or something, which could be satisfied by Mozilla, Firefox, Konqueror, lynx, links, w3m, Opera, even Amaya. Of course, there would be a default to install (probably Firefox or Konqueror), but if you already had a different browser installed, that would work, too.
But, we're really talking about apt vs yum. From what I was reading, the way yum/rpm handles dependencies is through files. That is, a package lists the files that it depends on, and the package manager finds out what packages provide those files.
On the other hand, apt, like most sane package managers (Gentoo's Emerge is another one), depends on other packages. And, there are all kinds of things you can do with them, including virtual packages, allowing for multiple alternate dependencies. For example, an RPM file that needs a web browser installed -- say, to display documentation -- might depend on
This also means that a package can depend on a specific version of another package, or have a minimum version required.
So, that's a pretty big fundamental difference, and it'd take a lot of thinking and probably a lot of deep, incompatible changes to make RPM come anywhere close.
Besides, apt is more popular at the moment, and it's used by Ubuntu, which is more popular at the moment. That means there are tons of really nice frontends for it, everyone's using it, everyone knows best practices for it, and so on. And, since it's open source, that also means everyone's developing it when it needs to be developed -- all kinds of people that might be interested in helping with RPM are already using Ubuntu and Apt, so they'd rather just add the feature to Apt.
I cannot think of a single thing that rpm/yum does that apt/dpkg doesn't. I've already listed something that apt/dpkg does well, that rpm/yum might possibly be able to do with a really ugly hack.
Think of it this way: FreeDOS could be improved. Linux could be improved as well. Which would you rather start with to make a modern OS?
Don't thank God, thank a doctor!
It's not universal, but neither is MSI. MSI works under Microsoft "distributions". Deb files work under apt/dpkg distros.
Don't thank God, thank a doctor!
No, the RPM Package Manager. The acronym was made recursive when they realized it is used by more than just Red Hat.
#!/bin/bash
..; echo $PWD)`"
/etc/slackware-version; then /etc/debian_version; then
date=`date +%Y%m%d`
name="`basename $PWD`"
[ "$name" == "src" ] && name="`basename $(cd
if test -d 'CVS'; then
args="--pkgversion=cvs.$date"
elif test -d '.svn'; then
args="--pkgversion=svn.$date"
elif test -d '.git'; then
args="--pkgversion=git.$date"
else
name="`echo "$name" | cut -d - -f 1`"
fi
if test -f SConstruct -o -f Sconstruct -o -f sconstruct; then
cmd="scons install"
else
cmd="make install"
fi
if test -e
t=slackware
elif test -e
t=debian
elif true #TODO: proper test for redhat
t=rpm
fi
cmd="sudo checkinstall --type=$t --nodoc --pkgname=\"$name\" $args $cmd"
echo "$cmd"
read -p "proceed ([y]/n)? " answer
test "$answer" == "y" -o "$answer" == "" || return
$cmd
factor 966971: 966971
Hey gang, using PCLinuxOS via Synaptic pretty much gets rid of the dependency hell - synaptic takes care of the dependency issues when installing. Uninstalling is another issue - just like Windows programs typically do, uninstalling doesn't leave you with the same footprint that was there before installing (i.e. some of the packages stay on the system that aren't needed). Anyhow, I've long forgotten about the RPM dependency hell and leave it to synaptic to figure it out and Redhat would be wise to follow the same format and improve synaptic for install/uninstall functionality while improving RPM.
Maybe you need:
:)
$ apt-cache search keyword
$ apt-file find filename
Those will show you the package you need. No need to switch distros and do everything by hand.
"Those who consume the bulk of goods are those who make them. We must never forget this secret of our prosperity."
Now, if only they would fix the embarrassing bug in RPM. :)
Since dpkg maintainer scripts are idempotent, reinstalling all the packages should have been a very straightforward way to get everything back.
:)
But the easiest way to get everything back would have been to restore your backups...
Since dpkg maintainer scripts are idempotent, reinstalling all the packages should have been a very straightforward way to get everything back.
:)
;)
Are *supposed* to be idempotent.
But the easiest way to get everything back would have been to restore your backups...
Smartarse
Still, from the perspective of being able to validate the installed state of packages, rpm is miles ahead of deb.
In the free world the media isn't government run; the government is media run.