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."
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
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.
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"
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
A better comparison would be dpkg to RPM.
Apt is a program that automatically resolves dependencies and fetches packages to install, among other things, and it sits on top of a packaging system, like dpkg or even RPM.
As for dpkg vs RPM, I can only say that I've never had as many problems with dpkg as RPM, especially when installing 3rd-party (unofficial to my distro) packages. I've also had fewer instances of "dependency hell" with dpkg than with RPM, and it's always been easier to fix when I have, but that has more to do with the package and distro maintainers than it does with the packaging system.
Yum, a popular RPM-based manager (like apt, but specifically for RPM) was certainly a total piece of shit the last time I tried it. Took about 10 times as long to do anything as apt would have for the same operation, and I'm not exaggerating. Maybe it's gotten better, but as recently as a couple years ago it was a huge pain in the ass to use. Apt for RPM seemed pretty good at the time, but I've not used it since. I don't even bother with RPM-based distros anymore, as, of the three systems I've used (dpkg+APT, Gentoo's Portage, and RPM) it was, hands down, the worst. It may be better these days, but then again I've found the recent Fedora builds that I've tryed out make me feel restricted, while simultaneously making me do more work than a modern dpkg-based distro probably would. For some reason, distros based on Debian seem to pick better defaults for newly-installed packages than RPM-based ones do, though I don't know why that is.
For reference, I've mostly used Mandrake, Debian, Gentoo, and Ubuntu over the years, with lesser but non-trivial amounts of time spent with Red Hat/Fedora and Slackware, and a tiny bit of time with Suse, so any bias in my opinions on the matter may be tied to this, but I really have found that package management was only ever something that I dreaded dealing with when I was on Mandrake and Red Hat/Fedora, and I didn't work with Suse enough to form an opinion on it. Switching to mostly non-RPM distros a few years back made most of my package management woes disappear instantly.
apt and rpm don't compete - they are not even similar in purpose - each fill a different role and are cooperative ratehr than competative.
.deb files and dpkg?
.debs a slightly better package structure/file structure than rpms, and dpkg a more flexible and easier to use (getting both is quite an achievement I think) command line.
.deb system as they very rarely run somehting like dpkg -i gcc-4.1.deb - usually they will type apt-get install build-essentials or apt-get install gcc and it will "just work" (or they will use dselect but thats another topic)
.deb files via apt (and lets face it - if you are sing a distro with .deb you are almost certainly using apt or dselect). This perception causes the view that rpm is crap and .deb/dpkg is far superior. The real problem is though not the package management tool at all. Its the repository management policy, something that debian and debian based projects has had right for a long time.
In fact apt can work quite well with rpms (the apt for rpm project springs to mind)
Maybe you are confusing the issue with
Personally I find
However those are personal preference and while not quite as contentious as emacs vs vi I'm sure they won't be solved any time soon.
You are right to bring up apt though - its apt that makes distros like ubuntu and debian shine. Or more importabltly its the repository organisation and discipline that sits behind apt. Without this organisation server side, the package files clearly listing each package which dependancies and conflicts, then the system is all but meaningless, and thats where apt for rpm has fallen down (not that it doesn't work, I've used it with several rpm respositories, its not bad but several times I've had to hand resolve large messy conflicts, I've had to do that on debian true, but only when doing really messy mixtures of sid sarge and woody all on one box during times of serious upheaval - gnome 1.4 to gnome 2 springs to mind)
Getting rpm and apt to run better together is not really about code changes or design changes to either apt or rpm (or the existing apt for rpm software). Its about making good rpm respositories and the package files that go with them - that would be a huge improvement for starters.
The main fustration people feel with rpm is dependancy resolving, being able to type rpm -i gcc-4.1.rpm and having it just work would be nice. People don't associate the same problem with the
I think that is what really colours peoples perceptions. They feel pain frequently when they use rpm (I know I do). They don't feel pain when using
$_="Slashdotter";$syn="OTT";s;..;;;sub _{print shift||$_};s!ash!Perl !;s=$syn=ack=i;tr+LLEd+BLAH+;_"Just Another ";_
I am not a Linux user, but I am a software developer, and it seems to me, that ALL the distros could benefit from a universal package manager, that was compatible with all the major package types?
Or do I completely mis-understand how things work under linux ?
-Jar.
Together, We Can Make Slashdot Better. I Do NOT Mod ACs. - Check Me Out
Worth to mention that apt now deprecated in favor of aptitude. Aptitude marks packages installed as part of dependency resolution and when you later remove the installed software, it would also remove all automatically installed packages.
+100. yum is dumbest and slowest tool I have ever seen. Especially when people try to pitch it against apt-get. And aptitude is ages ahead of any package management RedHat ever implemented.
All hope abandon ye who enter here.
If you hate dependency hell, you should try Slackware: no package dependency at all!
If you install a program and it doesn't run, check the console messages for the missing library (or just ask Google), and install it by hand.
factor 966971: 966971
Oh, yes, that is called inferno instead of hell.
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.
Apt is certainly not deprecated in favour of aptitude, as aptitude is a frontend to apt. One could argue that aptitude is superior to apt-get, but it should be noted that apt-get also has autoremoval, at least in Ubuntu. Try apt-get autoremove.
Personally, I have always used apt-get instead of aptitude.
Unfortunately at the moment most packages don't just contain files and meta data they also have this hacky distro-specific bit that actually runs commands directly on the system. Which is really quite crap.
For example a sane package format might have something like this to install a font. This would allow any system that supports truetype fonts to install it how it wants.
But you are more likely to see something like this: Which is actually a set of commands to install the font on a system with a particular X based font system and directory layout.
The requirements for packaging for Windows is fundamentally different than for Linux. The differences between distributions can be extremely large as Geekmeister mentioned, much larger than differences between versions of Windows, and there are innumerable places where things could vary.
How would a universal package for apache, for example, know how to set up starting and stopping the service? Different distributions put the scripts in different places, and use different formats and conventions for the scripts. In future versions of Ubuntu, the scripts won't even be shell scripts, and will be handled in a fundamentally different way. The meaning of installed dependencies is also different. USE flags in Gentoo would have to be considered, for example.
In order to make a package format that would work for everyone, the system would have to resemble autoconf, and check for every imaginable aspect of each system. Like the configure scripts of autoconf, doing so would make installation absurdly slow. The package format would also have to include many versions of files with the same purpose, making the packages very large.
In short, perhaps such a package format could be made, but it would be inferior to the formats that already exist. In fact, this is the case. Formats like autopackage and klik exist, but they are markedly inferior in terms of stability, reliability, elegance, and usefulness for non-trivial packaging requirements, and usually only used for end-user applications with few dependencies.
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!
I heard of such problem (though never used the apt-rpm by myself).
Most often the problem was attributed to RH/SUSE love to heavily patched software which leads to requirement to have rpm depend on precise version of the patched software (glibc, perl, python, kernel headers, etc).
Debian's packages normally try to be lax about dependencies: they do not depend on some particular version of other packages, but rather range of versions. e.g. some packaged doesn't depend on "glibc-2.3.99-cvs20041212", but rather on "glibc-2.4 and higher". (I still shiver recalling hell of manually upgrading RH/SUSE servers - after new release of glibc.)
IMHO, your problem is ideological incompatibility of apt and of rpms as provided by vendors.
On Debian with all Debian's repositories + several second party repositories, apt/aptitude does great job of finding compatible combination of packages to install: often it may resort even to downgrading some packages to satisfy dependencies and allow you to install request package.
All hope abandon ye who enter here.
I fail to see why your lack of understanding about how rpm works means that rpm should not be made better. The article is about making rpm better, whereas your post is about how hard it is to learn everything about Linux. While you may, in fact, have a valid point, your point doesn't mean that rpm shouldn't finally be made into a decent package manager.
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 ]
It's like your comment was written in 1999 and you just now posted it.
Why read the article when I can just make up a snap judgement?