Who maintains RPM? [LWN.net]

Who maintains RPM?

Posted Aug 23, 2006 1:10 UTC (Wed) by drag (guest, #31333)
Parent article: Who maintains RPM?

Sounds like a job for Freedesktop.org to me.

It's in the LSB so all distros have to support it, right?

I know it's not a 'desktop' issue for distros that use RPM for their native package format.. But it's a 'desktop' issue for Distros that don't use pm natively.

This is one of the major issues of Linux on the desktop right now, right? A universal package format for resolving dependancies and such?

So maybe setup a situation like with X.org and Freedesktop.org, but instead revive RPM.org and tied that into Freedesktop.org. Call it 'rpm-ng' or maybe 'upm' for 'universal package management system'.. Or something like that.

Keeping in mind the entire time that RPM has to be supported for LSB compatability and generally distros seem to value that.

So for tying into distros that only support rpms in a teriary way you could create a set of generic management utilties and libraries for handling RPM and then have some hooks were distros can utilize their own package mangement systems to resolv dependancies.

They could use a semi-intellegent method like:
Person double clicks on rpm file for very-important-program.
Dependancies are analized and semi-intellegent list of possible and recommended packages from the native distro system are displayed were a user could click on to change if they felt like it, or choose a dependancy themselves if the system fails to find a match.

So you kinda meat the distros half-way. You take care of the RPM side, provide some nice hooks, and the distros takes that and customizes it to fit into their own system.

Maybe if they do a realy good job maybe there could be a way to standardize package management system like we standardize around a GUI display system or whatnot.

I donno. Base the requirements for rpm-ng on best-of-breed examples of systems in use today..
For instance apt-get is the most usefull and mature system I've used. With the 'wajig' python-based command line front end it sort of combines all the functions into a single overal system.
What I am able to do with wajig is:
~$ wajig list-commands
All JIG commands:

addcdrom Add a CD-ROM to the list of available sources of packages
auto-alts Mark the alternative to be auto set (using set priorities)
auto-clean Remove superseded deb files from the download cache
auto-download Do an update followed by a download of all updated packages
auto-install Perform an install without asking questions (non-interactive)
available List versions of packages available for installation
bug Check reported bugs in package using the Debian Bug Tracker
build Retrieve/unpack sources and build .deb for the named packages
build-depend Retrieve packages required to build listed packages
changelog Retrieve latest changelog for the package
clean Remove all deb files from the download cache
commands List all the JIG commands and one line descriptions for each
daily-upgrade Perform an update then a dist-upgrade
dependents List of packages which depend/recommend/suggest the package
describe One line description of packages (-v and -vv for more detail)
describe-new One line description of new packages
detail Provide a detailed description of package (describe -vv)
detail-new Provide a detailed description of new packages (describe -vv)
dist-upgrade Upgrade to new distribution (installed and new rqd packages)
docs Equivalent to help with -verbose=2
download Download package files ready for an install
file-download Download packages listed in file ready for an install
file-install Install packages listed in a file
file-remove Remove packages listed in a file
find-file Search for a file within installed packages
find-pkg Search for an unofficial Debian package at apt-get.org
fix-configure Perform dpkg --configure -a (to fix interrupted configure)
fix-install Perform apt-get -f install (to fix broken dependencies)
fix-missing Perform apt-get --fix-missing upgrade
force Install packages and ignore file overwrites and depends
help Print documentation (detail depends on --verbose)
hold Place listed packages on hold so they are not upgraded
init Initialise or reset the JIG archive files
install Install (or upgrade) one or more packages or .deb files
installr Install package and associated recommended packages
installrs Install package and recommended and suggested packages
installs Install package and associated suggested packages
install/dist Install packages from specified distribution
integrity Check the integrity of installed packages (through checksums)
large List size of all large (>10MB) installed packages
last-update Identify when an update was last performed
list List the status and description of installed packages
list-all List a one line description of given or all packages
list-alts List the objects that can have alternatives configured
list-cache List the contents of the download cache
list-commands List all the JIG commands and one line descriptions for each
list-daemons List the daemons that JIG can start/stop/restart
list-files List the files that are supplied by the named package
list-hold List those packages on hold
list-installed List packages (with optional argument substring) installed
list-log List the contents of the install/remove log file (filtered)
list-names List all known packages or those containing supplied string
list-orphans List libraries not required by any installed package
list-scripts List the control scripts of the package of deb file
list-section List packages that belong to a specific section
list-section List the sections that are available
list-status Same as list but only prints first two columns, not truncated
list-wide Same as list but avoids truncating package names
local-dist-upgrade Dist-upgrade using packages already downloaded
local-upgrade Upgrade using packages already downloaded, but not any others
madison Runs the madison command of apt-cache.
move Move packages in the download cache to a local Debian mirror
new List packages that became available since last update
news Obtain the latest news about the package
new-upgrades List packages newly available for upgrading
non-free List installed packages that do not meet the DFSG
orphans List libraries not required by any installed package
package Generate a .deb file for an installed package
policy From preferences file show priorities/policy (available)
purge Remove one or more packages and configuration files
purge-depend Purge package and those it depend on and not required by others
purge-orphans Purge orphaned libraries (not required by installed packages)
readme Display the package's README file from /usr/share/doc
recursive Download package and any packages it depends on
recommended Install package and associated recommended packages
reconfigure Reconfigure the named installed packages or run gkdebconf
reinstall Reinstall each of the named packages
reload Reload daemon configs, e.g., gdm, apache (see list-daemons)
remove Remove one or more packages (see also purge)
remove-depend Remove package and its dependees not required by others
remove-orphans Remove orphaned libraries (not required by installed packages)
repackage Generate a .deb file for an installed package
reset Initialise or reset the JIG archive files
restart Stop then start a daemon, e.g., gdm, apache (see list-daemons)
rpm2deb Convert a RedHat .rpm file to a Debian .deb file
rpminstall Install a RedHat .rpm package
rpmtodeb Convert a RedHat .rpm file to a Debian .deb file
search Search for packages containing listed words
search-apt Find local Debian archives suitable for sources.list
setup Configure the sources.list file which locates Debian archives
show Provide a detailed description of package [same as detail]
showdistupgrade Trace the steps that a dist-upgrade would perform
showinstall Trace the steps that an install would perform
showremove Trace the steps that a remove would perform
showupgrade Trace the steps that an upgrade would perform
size Print out the size (in K) of all, or listed, installed packages
sizes Print out the size (in K) of all, or listed, installed packages
snapshot Generates list of package=version for all installed packages
source Retrieve and unpack sources for the named packages
start Start a daemon, e.g., gdm, apache (see list-daemons)
status Show the version and available version of packages
status-match Show the version and available version of matching packages
status-search Show the version and available version of matching packages
stop Stop a daemon, e.g., gdm, apache (see list-daemons)
suggested Install package and associated suggested packages
tasksel Run the Gnome task selector to install groups of packages
toupgrade List packages with newer versions available for upgrading
unhold Remove listed packages from hold so they are again upgraded
unofficial Search for an unofficial Debian package at apt-get.org
update Update the list of down-loadable packages
update-alts Update default alternative for things like x-window-manager
update-pci-ids Updates the local list of PCI ids from the internet master list
update-usb-ids Updates the local list of USB ids from the internet master list
upgrade Upgrade all of the installed packages or just those listed
versions List version and distribution of (all) packages.
whatis A synonym for describe
whichpkg Find the package that supplies the given command or file

Command line options:

-h|--help Print usage message.
-q|--quiet Do system commands everything quietly.
-n|--noauth Allow packages from unathenticated archives.
-s|--simulate Trace but don't execute the sequence of underlying commands.
-t|--teaching Trace the sequence of commands performed.
-v|--verbose=n Increase (or set) the level of verbosity (to n).
-y|--yes Assume yes for any questions asked.

Fuller documentation can be found at http://www.togaware.com/wajig.

So that thing is very usefull. It makes it trivially easy to do things like recompile programs from Debian Unstable to use on Debian stable. Very easy. Don't have to do pinning or anything like that. Try it out some time.

Then there is things like check-install were you can pretty much generate your own packages on the fly.

Then there is 'smart', which does pretty intellegent way of managing dependancies...
Although I would REEAALY prefer a human editable way to configure it. Binary only configuration files suck.

It just seems to me that packages as they are now have a lot of obvious flaws and f-ups and such. They were designed before their was realy effective package management. Maybe it's time to take years and years of experiance and make something that is simple yet effective.

to post comments

Who maintains RPM?

Posted Aug 23, 2006 7:19 UTC (Wed) by rsidd (subscriber, #2582) [Link] (7 responses)

It's in the LSB so all distros have to support it, right?

This is a slightly ridiculous situation. Back when the LSB idea came up, everyone did use RPM, except Debian which only a few geeks used anyway, and Slackware which hardly had package management. So requiring RPM in the LSB may have made some sort of sense.

Today the situation is different: most of the newer distributions (Ubuntu, Linspire, Xandros, Mepis, ...) have chosen to base themselves on Debian and its package management system. Clearly this was for technological reasons and not for marketing reasons. It makes no sense to require these distributions to support RPM. Debian is a standard of its own, that has survived and thrived on its technical merits, not by being imposed top-down.

A few years ago, Debian had a forbidding reputation, and RPM hell was one of the factors that drove me to FreeBSD. Then I discovered (via Knoppix) how easy Debian really was, and moved back. Now I use Ubuntu.

If Red Hat and SuSE could figure out a way to switch to deb and apt, and abandon RPM altogether, the linux world would be a better place.

Who maintains RPM?

Posted Aug 23, 2006 11:39 UTC (Wed) by drag (guest, #31333) [Link]

Well Debian does support installing RPM packages, though, through the alien stuff.

As you see in the wajig list-command output it has a couple (somewhat redundant) commands for handling rpm format.

So I figure that Debian-based systems should support it also, even if it's not in a official capacity.

For ISVs then it would make sense to target RPM for packages. Debian supports it, Debian-based systems should support it, but Redhat and such don't support Deb packages.

What is left is just making it sane to use in non-native-rpm systems for the average end user.. if a thing is ever possible. (which I have no idea about)

Who maintains RPM?

Posted Aug 23, 2006 17:46 UTC (Wed) by nevyn (guest, #33129) [Link] (3 responses)

This is a slightly ridiculous situation.

Not at all, if the software is open source debian can just package it themself. If it's closed then Red Hat and Novell still have almost all the market, and debian/ubuntu have alien support.

If Red Hat and SuSE could figure out a way to switch to deb and apt, and abandon RPM altogether, the linux world would be a better place.

Why would they screw their customers over like that, the deb format is not any better than the rpm format (has Suggests/Enhances doesn't have file deps). The dpkg tool is much worse than rpm, IMNSHO, and the higher level tools (yum, apt-get, smart, open-carpet, etc.) are all roughly equal technically. Also (from a long time Red Hat/Fedora users POV) the base system in debian is very different, and one of the main reasons I don't use ubuntu.

Ubuntu didn't base off of debian because it was technically better, they did it because it was bigger ... plus IMO because there were more unemployed people who know debian well than know Red Hat well, which you might take as a flame but I can't help that...

Who maintains RPM?

Posted Aug 24, 2006 2:12 UTC (Thu) by robla (guest, #424) [Link] (2 responses)

Ummm...please. Ubuntu is based on Debian because Mark Shuttleworth is a long time Debian guy, and he writes the checks. I'm sure at least some of the reason /why/ he's a long time Debian guy is because he felt as though Debian was a superior starting point, though I don't pretend to speak for him. Your assessment, however, is highly implausible.

Who maintains RPM?

Posted Aug 24, 2006 12:35 UTC (Thu) by madscientist (subscriber, #16861) [Link] (1 responses)

Not only that, but Debian is 100% developed, directed, and controlled by volunteers. They have a robust constitution and regular public elections, open to all developers. Anyone in the world can become a Debian Developer. The distribution is completely free AND completely open. Red Hat and Fedora are absolutely inappropriate for serving as the basis for a major new Linux distribution such as Ubuntu.

Who maintains Debian?

Posted Aug 31, 2006 21:31 UTC (Thu) by gvy (guest, #11981) [Link]

> a robust constitution
I've heard differing opinions from Debian folks, regarding "robust".

> Anyone in the world can become a Debian Developer.
Especially if said anyone is to become the first DD in the country. Well here in Ukraine, they've trusted ALT Linux security officer who has signed my key before, and so I've signed the particular person on meeting him (it appeared we've graduated the same university, even). Wonder if this was not the case.

Just to put some sane facts over your mad science. :)

Who maintains RPM?

Posted Aug 24, 2006 12:42 UTC (Thu) by madscientist (subscriber, #16861) [Link]

The whole LSB-uses-RPM thing is just a tempest in a teapot; even the Debian developers don't care about this. Why? Because an LSB-compliant package is so restrictive that it completely does not matter which package format it uses. The legal fields in an LSB RPM package are a strict subset of "full-blown" RPM. They can list dependencies ONLY on a very limited set of prerequisites: basically only on a package representing the LSB version (and maybe other 3rd party LSB packages; it's been a while since I read the spec). As already mentioned, the LSB does not require that the underlying distribution use RPM or any other particular package management tool: only that there be some application "rpm" which can install and uninstall packages that use this specific subset of RPM.

So yes, it may be slightly more work for non-RPM-based distributions to create a translator between RPM and their native package management, but it's certainly not difficult and, in fact, has already been done with alien.

So, it's just not worth arguing about this, or expending any effort to change it. IMO.

Who maintains RPM?

Posted Aug 30, 2016 17:07 UTC (Tue) by Wol (subscriber, #4433) [Link]

> If Red Hat and SuSE could figure out a way to switch to deb and apt, and abandon RPM altogether, the linux world would be a better place.

And then we end up with the same nightmare that we had between Red Hat and SuSE. Where the RH/SuSE debs will have clashing names for different contents etc etc. And who gives way and changes packaging policy?

Can anyone name a apt/deb distro that is NOT a debian derivative? They've inherited the original packaging/naming policy, and can be declared out-of-line if they're different. When SuSE adopted rpm, they had an existing policy. If RH/SuSE adopt apt/deb, they will bring that same problem to the .deb world.

Cheers,
Wol

Who maintains RPM?

Posted Aug 30, 2016 17:00 UTC (Tue) by Wol (subscriber, #4433) [Link]

> Sounds like a job for Freedesktop.org to me.

> It's in the LSB so all distros have to support it, right?

Wrong. rpm the program is NOT in the lsb.

A subset of the rpm spec is in the lsb. Most importantly, if you use rpm features that are not supported by alien, then you cannot be lsb-compliant.

Declaration of interest - I was part of the lsb when all this was hashed out. I didn't particularly agree with what the lsb was doing back then, nor do I agree now, but I got involved to try and influence things. Unfortunately (from my pov) the juggernaut was not for turning ...

Cheers,
Wol