Fedora Project to Help Revitalize RPM 334
-=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."
Come again on that one? (Score:5, Informative)
That would be the Redhat Package Manager, right?
Re:You Have It All Wrong (Score:4, Informative)
Yum and others handles repositories and dependency solving.
Re:I've got something to say! (Score:5, Informative)
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
Re:I've got something to say! (Score:2, Informative)
# yum install anjuta
Since Anjuta is in the Fedora Extras repository you might have to enable that first (i.e. add "--enablerepo=extras" to the previous yum command line)
Actually, I just tried it. It worked fine:
Re:I've got something to say! (Score:5, Informative)
Or do I completely mis-understand how things work under linux ?
-Jar.
Re:I've got something to say! (Score:5, Informative)
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.
Re:wow (Score:3, Informative)
Fortunately, db4 seems to be dead: it's been replaced in such lightweight applications by SQLite, there are a lot more and faster mirrors available, and the repository information is stored more effiently, or at least handles a lot faster with faster modern machines. So it's overall gotten a lot better: take a look at the versions of the past year or two to see how good it's gotten.
Re:I've got something to say! (Score:2, Informative)
First of all open a terminal and edit
near the end of the file uncomment so it looks like this:
Code:
if [ -f ~/.bash_aliases ]; then
. ~/.bash_aliases
fi
alias h=history
alias untgz="tar -xvfz"
alias untbz2="tar -xvfj"
Re:Good. (Score:4, Informative)
You can roughly emulate package dependency using specific files (or symlinks) within packages which are just there to deal with dependencies, but it's messy compared to a system designed properly from the outset.
Dumb Asses (Score:1, Informative)
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.
*Package-format* to take care of ? (Score:5, Informative)
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 [wikipedia.org]).
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 [slashdot.org] 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).
Re:I've got something to say! (Score:3, Informative)
Yes it is possible for an emerge to break after you have been compiling for a huge amount of time, but this has nothing to do with a dependency, it has to do with either a the codebase on the application you are using being broken or the ebuild itself being broken.
This being said I personally use gentoo because I actually like having that much control over my system, I recently installed Suse 10.1 on my wifes computer and was seriously disappointed since the package updater was broken (I used suse from version 6.0 - 9.0) and I used to have a nightmare with dependencies almost everytime I installed a package. I used fedora at a company I used to work at and got to the point where I would dread having to install anything because of the dependency problems. I used debian and I was fairly impressed, however, I got fed up with having to use out of date packages. I have recently install Ubuntu on my wifes computer and overall I have been very impressed with it, so far I haven't had any dependency problems whatsoever.
Taking a step back, I am not attempting to knock anyone elses preferences, I am just expressing my experience with the various package managers, so far the most impressive for me have been portage on gentoo and apt/dpkg on ubuntu.
Re:I have a suggestion (Score:1, Informative)
Installing from source on an RPM/DEB system. (Score:3, Informative)
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 [labix.org] 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
Re:Good. (Score:1, Informative)
As for virtual packages, they're perfectly possible with RPM too, that's what Provides is for. For example, firefox, dillo, elinks, lynx and wget provide the virtual "webclient" package, httpd, boa and others provide the virtual "webserver" package.
Re:I've got something to say! (Score:3, Informative)