The newest version of the popular RPM package manager is now out with improved performance and functionality. But there’s a bit of a catch with RPM version 5.0. Linux vendor Red Hat officially considers RPM 5.0 a project fork. “RPM5 is a fork of RPM, and is not related to RPM.org,” Daniel Riek, Product Manager Red Hat Enterprise Linux told InternetNews.com. “Neither Red Hat or Fedora are involved in RPM5, and have no current plans to use it. Red Hat remains committed to the main RPM.org releases and development.”
we still dont know whether the official rpm.org is alive or dead, what improvements have redhat/Fedora made to 4.4.2.2? i dont see why redhat just dont make a new package Manager an boycott rpm for good maybe call it DPM ? Delta Package Manager
I’m not surprised RH boycotts rpm5. Just have a look at its founder’s openmindness, Jeff Johnson:
https://bugzilla.redhat.com/show_bug.cgi?id=119185
Just read all his replies. You definitely don’t want to mix with this kind of negative person.
It’s a classic case of an overgrown ego — the guy is afraid of admitting to a mistake publicly. I’m sure he bears no ill will. Most likely when this cools down he’ll have it fixed quietly or call the fix an improvement.
Fedora/ Red Hat makes improvements directly in rpm.org and maintains that branch and hence has no real need to deviate from it. As far as improvements are concerned read the news section in http://rpm.org
with that said. is rpm4.4.2.2 just as fast as rpm5? as Jeff Johnson claims it is?
I can claim it is but the only real way to know is for someone to do proper benchmarks and post the results for analysis to the rpm-maint list at http://rpm.org.
Somebody is forking Apt? 😉
rpm is not Apt
Kind of my point. The title makes it sound like rpm is the only package manager available for Linux.
…. Sigh.
For 100,000’th time.
RPM (Redhat Package Manager) is a package manager.
dpkg (Debian package) is a package manager.
Yum (Yellow Dog Updater) is the RPM package manager front-end.
apt (Advanced Packaging Tool) is a package manager front-end.
Got it?
– Gilboa
Neat, you’re right! Ubuntu uses dpkg! http://en.wikipedia.org/wiki/Dpkg
Edited 2008-01-10 01:44 UTC
> Yum (Yellow Dog Updater) is the RPM package manager front-end.
> apt (Advanced Packaging Tool) is a package manager front-end.
You can use apt (and synaptic) as frond-end for rpm :
http://apt-rpm.org/
You could also use yum as a front-end to dpkg, but so far no one has done so. Something about apt being perfect, I think…
You can use apt (and synaptic) as frond-end for rpm
Absolutely. In fact, that is the default for PCLinuxOS.
You can use apt (and synaptic) as frond-end for rpm
Absolutely. In fact, this is the default in PCLinuxOS.
What I don’t like is when I run Fedora there are constant issues; for example, the db which holds all the information constantly being locked by another process – there should be no need in this day and age of a ‘one at a time please’ approach to applications reading and writing to the package database. If it can’t be done with the existing structure then they need to go back to the drawing board and address the deficiencies which stop it from being made possible.
The other issue, maybe this is more project related, is the fact I’ve tried to update packages, and package resolving is horrid. I’ve never experienced the same pain with Ubuntu/Debian as I do with Fedora 8. New updates come this morning, I click on apply updates, it then complains that there is a missing file – why isn’t that being resolved automatically – it should reside in the repository!
That is I think the biggest problem, those who do use RPM do a cruddy job in its utilisation, and thus, when people have problems like when I do, they equate that to representing RPM when it is a distro specific issue.
Problems with yum and RPM in Fedora helped pushed me towards Ubuntu. apt, dpkg, and .deb seem so much better for keeping the system up to date.
Agreed…
And typing
update-manager -d -c
to upgrade between versions is totally amazing.
“What I don’t like is when I run Fedora there are constant issues; for example, the db which holds all the information constantly being locked by another process – there should be no need in this day and age of a ‘one at a time please’ approach to applications reading and writing to the package database.”
A. This problem is not RPM related – it’s actually yum-related. (Yum is limited to one active instance – mostly due to problem C and friends).
B. AFAIR (correct me if I’m wrong) neither apt not dpkg doesn’t support concurrent write operations either. (I can’t test it right now; my Debian sid machine is down)
C. Concurrent writes (in both the package manager and the package manager front end) creates theoretical problems that cannot be easily solved. E.g. Yum1 installs application A that requires library B. B provides foo. Yum2 installs application C that requires library D. D provides foo. Obviously, B and D cannot be installed concurrently – but the package manager (again, RPM/dpkg, not apt/yum) doesn’t know who provides what – before things get installed.
At best, (if the package manager update transactions remain atomic) one update will fail – after you finished downloading the application + dependencies for weird obscure reason. (D provides foo, B (installed) provides foo, cannot install)
On the other hand, if the package manager supports concurrent updates, (each install/update is a transaction by itself), you may end up with a broken installation.
D. The package manager itself is a fairly speedy beast. Installing 100 packages takes a minute or two. No use in risking DB breakage just to speed up such a short-lived task.
“The other issue, maybe this is more project related, is the fact I’ve tried to update packages, and package resolving is horrid. I’ve never experienced the same pain with Ubuntu/Debian as I do with Fedora 8. New updates come this morning, I click on apply updates, it then complains that there is a missing file – why isn’t that being resolved automatically – it should reside in the repository!”
As you suggested – this is a repository problem.
More-ever, AFAIR apt simply drops broken update paths. Yum doesn’t.
If you want yum to drop broken updates, simply install the yum-skip-broken plugin.
$ yum install yum-skip-broken
$ yum –skip-broken update
… I do agree that yum should ship with skip-broken and fastest mirrors (mirror auto-selection tool) by default.
– Gilboa
Edited 2008-01-10 02:04 UTC
> AFAIR apt simply drops broken update paths.
And this is really wrong.
If you have a security update, it should be applied. If the paquage manager can’t apply the update, they should tell what the problem is (and trust me, yum do the right job in 99,999 % of time). The user can then take a decision (retry later, evaluate the issue, get help, bugzilla, etc). This is what does Yum, and Yum is right. Apt can silently ignore a security update for month.
This is a known problem.
Option A: Stop the update process – but risk blocking -other- security updates.
Option B: Drop broken updates – but risk having silent security risks.
… In my view, there’s option C:
Stop when encountering broken updates, notify the user, and let the user decide if it wants to continue (while dropping the updates) or not.
– Gilboa
> This is a known problem.
It’s not a problem, it’s a bug. And it must be fixed.
Sometime you can’t update Fedora. But it’s almost for 3 days.
How many time this append per year ?
2 or 4 times. Not more.
> I do agree that yum should ship with skip-broken
No.
> mirror auto-selection tool
$ yum info yum-fastestmirror
Name : yum-fastestmirror
[…]
Description:
This plugin sorts each repository’s mirrorlist by connection speed
prior to downloading packages.
Just “yum install yum-fatestmirror”.
I never use it.
Or check /etc/yum/yum-updatesd.conf :
# automatically install updates
do_update = no
# automatically download updates
do_download = no
# automatically download deps of updates
do_download_deps = no
> the db which holds all the information constantly being locked by another process
It’s a very very very old story.
> is the fact I’ve tried to update packages, and package resolving is horrid.
Bullshit ?
Why should rpm have resolving issue ?
Give some technical fact, please.
> it then complains that there is a missing file
If a file is missing on a mirror, the file is missing. Period.
What can rpm (or yum) handle this ?
Silently ignore the problem ?
Some package manager do this. I think they are really wrong.
I haven’t changed a thing on my Fedora setup, I have left it to the status quo. Fedora setup the the mirrors, which IIRC is a php script which redirects me to an authorised mirror. How is it my fault, as an end user that the authorised mirrors aren’t doing their job properly.
In regards to the issue. It is a missing dependency; there is an update for Rhythmbox, which has a dependency on libgpod which is being updated as there is new support for iPod Classic etc. etc. It complains about the lack of libsgutils.so.1 which isn’t provided; so all it does is throw up a complaint – something which is on the shoulders of Fedora.
BUT! like I said, this has more to do with the shoddy work by Fedora/Red Hat than possibly anything to do with RPM per-say.
Edited 2008-01-10 04:46 UTC
I dont know what you did, but I just downloaded the latest version from the official Fedora mirrors and I didnt get that error. The only reason why you would get that is that you happened to update your software while the repository was in the middle of updating. I suspect if you try again a bit later, the problem will be resolved.
> How is it my fault
It is not. Sure.
> It is a missing dependency; there is an update for Rhythmbox
# yum install rhythmbox.x86_64
Loading “downloadonly” plugin
fedora 100%
[…]
Setting up Install Process
Parsing package install arguments
Resolving Dependencies
–> Processing Dependency:
[…]
libsgutils.so.1()(64bit) for package: libgpod
–> Running transaction check
—> Package sg3_utils-libs.x86_64 0:1.23-2.fc8 set to be updated
–> Finished Dependency Resolution
Dependencies Resolved
==========
Package Arch Version Repository Size
==========
Installing:
rhythmbox x86_64 0.11.3-6.fc8 updates 5.0 M
Installing for dependencies:
libgpod x86_64 0.6.0-3.fc8 updates 235 k
libmusicbrainz x86_64 2.1.5-2.fc8 fedora 104 k
sg3_utils-libs x86_64 1.23-2.fc8 fedora 48 k
[…]
Installed: rhythmbox.x86_64 0:0.11.3-6.fc8
Dependency Installed: libgpod.x86_64 0:0.6.0-3.fc8 libmusicbrainz.x86_64 0:2.1.5-2.fc8 sg3_utils-libs.x86_64 0:1.23-2.fc8
Complete!
> It complains about the lack of libsgutils.so.1 which isn’t provided
# rpm -q –provides sg3_utils-libs
libsgutils.so.1()(64bit) <== installed (see above)
sg3_utils-libs = 1.23-2.fc8
And for i386 :
# yum whatprovides libsgutils.so.1
Loading “downloadonly” plugin
fedora 100%
[…]
sg3_utils-libs.i386 : Shared library for sg3_utils
Perhaps you hit a bad mirror.
I agree that Fedora does have that problem sometimes, but I have had a similar experience running Kubuntu. More than once I have tried to download updates when notified only for apt to tell me that a package is broken or will not be installed because it WILL break another package. My opinion is not that is it the package manager’s fault so much as it is the package maintainers.