Linked by Thom Holwerda on Wed 9th Jan 2008 22:24 UTC, submitted by darthtalon
General Development 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."
Order by: Score:
rpm.org dead?
by Sabz on Wed 9th Jan 2008 22:54 UTC
Sabz
Member since:
2005-07-07

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 ;)

Reply Score: 1

RE: rpm.org dead?
by Joe User on Thu 10th Jan 2008 01:10 UTC in reply to "rpm.org dead?"
Joe User Member since:
2005-06-29

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.

Reply Score: 2

RE[2]: rpm.org dead?
by unavowed on Thu 10th Jan 2008 12:38 UTC in reply to "RE: rpm.org dead?"
unavowed Member since:
2006-03-23

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.

Reply Score: 1

RE: rpm.org dead?
by Rahul on Thu 10th Jan 2008 01:51 UTC in reply to "rpm.org dead?"
Rahul Member since:
2005-07-06

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

Reply Score: 3

RE[2]: rpm.org dead?
by Sabz on Thu 10th Jan 2008 06:27 UTC in reply to "RE: rpm.org dead?"
Sabz Member since:
2005-07-07

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?

Reply Score: 1

RE[3]: rpm.org dead?
by Rahul on Thu 10th Jan 2008 07:29 UTC in reply to "RE[2]: rpm.org dead?"
Rahul Member since:
2005-07-06

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.

Reply Score: 2

What?
by BluenoseJake on Wed 9th Jan 2008 23:37 UTC
BluenoseJake
Member since:
2005-08-11

Somebody is forking Apt? ;-)

Reply Score: 2

RE: What?
by Sabz on Thu 10th Jan 2008 00:37 UTC in reply to "What?"
Sabz Member since:
2005-07-07

Somebody is forking Apt? ;-)

rpm is not Apt

Reply Score: 3

RE[2]: What?
by BluenoseJake on Thu 10th Jan 2008 00:55 UTC in reply to "RE: What?"
BluenoseJake Member since:
2005-08-11

Kind of my point. The title makes it sound like rpm is the only package manager available for Linux.

Reply Score: 3

RE[3]: What?
by gilboa on Thu 10th Jan 2008 01:23 UTC in reply to "RE[2]: What?"
gilboa Member since:
2005-07-06

.... 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

Reply Score: 9

RE[4]: What?
by Luminair on Thu 10th Jan 2008 01:41 UTC in reply to "RE[3]: What?"
Luminair Member since:
2007-03-30

Neat, you're right! Ubuntu uses dpkg! http://en.wikipedia.org/wiki/Dpkg

Edited 2008-01-10 01:44 UTC

Reply Score: 3

RE[4]: What?
by superman on Thu 10th Jan 2008 04:13 UTC in reply to "RE[3]: What?"
superman Member since:
2006-08-01

> 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/

Reply Score: 2

RE[5]: What?
by sorpigal on Thu 10th Jan 2008 17:31 UTC in reply to "RE[4]: What?"
sorpigal Member since:
2005-11-02

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...

Reply Score: 1

RE[5]: What?
by KenJackson on Thu 10th Jan 2008 22:21 UTC in reply to "RE[4]: What?"
KenJackson Member since:
2005-07-18

You can use apt (and synaptic) as frond-end for rpm

Absolutely. In fact, that is the default for PCLinuxOS.

Reply Score: 1

RE[5]: What?
by KenJackson on Thu 10th Jan 2008 22:32 UTC in reply to "RE[4]: What?"
KenJackson Member since:
2005-07-18

You can use apt (and synaptic) as frond-end for rpm

Absolutely. In fact, this is the default in PCLinuxOS.

Reply Score: 1

What I don't like...
by kaiwai on Thu 10th Jan 2008 00:05 UTC
kaiwai
Member since:
2005-07-06

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.

Reply Score: 4

RE: What I don't like...
by Johann Chua on Thu 10th Jan 2008 01:35 UTC in reply to "What I don't like..."
Johann Chua Member since:
2005-07-22

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.

Reply Score: 5

RE[2]: What I don't like...
by raver31 on Thu 10th Jan 2008 11:29 UTC in reply to "RE: What I don't like..."
raver31 Member since:
2005-07-06

Agreed...

And typing

update-manager -d -c

to upgrade between versions is totally amazing.

Reply Score: 3

RE: What I don't like...
by gilboa on Thu 10th Jan 2008 01:58 UTC in reply to "What I don't like..."
gilboa Member since:
2005-07-06

"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

Reply Score: 5

RE[2]: What I don't like...
by superman on Thu 10th Jan 2008 04:31 UTC in reply to "RE: What I don't like..."
superman Member since:
2006-08-01

> 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.

Reply Score: 1

RE[3]: What I don't like...
by gilboa on Thu 10th Jan 2008 09:54 UTC in reply to "RE[2]: What I don't like..."
gilboa Member since:
2005-07-06

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

Reply Score: 2

RE[4]: What I don't like...
by superman on Thu 10th Jan 2008 10:43 UTC in reply to "RE[3]: What I don't like..."
superman Member since:
2006-08-01

> 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.

Reply Score: 1

RE[2]: What I don't like...
by superman on Thu 10th Jan 2008 04:37 UTC in reply to "RE: What I don't like..."
superman Member since:
2006-08-01

> 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

Reply Score: 1

RE: What I don't like...
by superman on Thu 10th Jan 2008 04:27 UTC in reply to "What I don't like..."
superman Member since:
2006-08-01

> 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.

Reply Score: 2

RE[2]: What I don't like...
by kaiwai on Thu 10th Jan 2008 04:40 UTC in reply to "RE: What I don't like..."
kaiwai Member since:
2005-07-06

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

Reply Score: 3

RE[3]: What I don't like...
by TechGeek on Thu 10th Jan 2008 05:23 UTC in reply to "RE[2]: What I don't like..."
TechGeek Member since:
2006-01-14

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.

Reply Score: 2

RE[3]: What I don't like...
by superman on Thu 10th Jan 2008 05:57 UTC in reply to "RE[2]: What I don't like..."
superman Member since:
2006-08-01

> 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.

Reply Score: 2

RE: What I don't like...
by VenomousGecko on Thu 10th Jan 2008 15:41 UTC in reply to "What I don't like..."
VenomousGecko Member since:
2005-07-06

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.

Reply Score: 1