Who maintains RPM?
Once upon a time, RPM was the "Red Hat Package Manager." In a bid to establish RPM as a wider standard - and, perhaps, to get some development help - Red Hat tried to turn RPM into a community project - rebranding it as the "RPM Package Manager" in the process. But core RPM development remained at Red Hat, under the care of an employee named Jeff Johnson. That, it would seem, is where the trouble starts.
Back in early 2004, an RPM bug report was filed. The reporting user had made a little mistake, in that he had tried to install a package on a system where /usr was mounted read-only. Needless to say, this operation did not work as intended - an outcome which the bug reporter could live with. This person, however, did think that it might have been better if RPM had not corrupted its internal database in the process of failing. He suggested that RPM should keep its internal records in order, even if the system administrator has requested something which cannot be done.
The ensuing conversation - lasting for over two years - deserves to become a textbook example in how not to respond to bug reports. Mr. Johnson took the position that, since RPM was being asked to do something erroneous, its subsequent mangling of the package database was not a bug. Instead, it seems, this behavior should be seen as an appropriate consequence for having done something stupid. Mr. Johnson repeatedly closed the bug, stating his refusal to fix it. Numerous other participants in the discussion made it clear that they disagreed with this "resolution" of the bug, but nothing, it seemed, could convince the RPM maintainer to put in a fix.
In February, 2006 - almost two years after the bug report had been entered - Mr. Johnson posted a one-line comment to the effect that read-only mounts were properly detected in RPM-4.4.5. This might seem like the end of the story, except for one little problem: Fedora currently ships version 4.4.2, and even the Fedora development repository has not gone beyond that. SUSE remains at 4.4.2, and the current RHEL offerings have rather older versions. Mr. Johnson has continued to make RPM releases, but the distributors are not picking them up. They are, instead, shipping an older version of this crucial tool, augmented with a rather hefty list of patches.
Part of what is happening here is that Mr. Johnson is no longer a Red Hat employee, having been encouraged to pursue other opportunities. He does, however, continue to show up on the Red Hat bug tracker when RPM issues are being discussed; as a current example shows, he does not appear to have adopted a friendlier attitude toward RPM users (or his former employer) over time. There has been talk on the mailing lists about removing his access to the bugzilla database - an action which may have occurred by now.
Red Hat's Greg DeKoenigsberg, who has responsibility for the company's relations with the development community has stood up and pointed out, however, that simply silencing one difficult personality will not address the real problem:
Fast forward a year plus, and here we are. We're in a position where we have, essentially, forked RPM -- and no one is willing to admit it. No one is willing to take ownership of what we've done.
Perhaps jbj "owns" RPM, in its current incarnation, by default, because no one else is willing to touch it. That's fine. He can have it. But that is not what *we* are using.
So, when Jeff Johnson walked out the door at Red Hat, he took RPM with him. Since then, few distributors have wanted to use his releases, but no other organized project around RPM has come into existence. For the purposes of the people using distributions from Red Hat and SUSE, RPM is essentially unmaintained.
There has been no clear message to users about the state of RPM. Some Fedora users have asked, via yet another bugzilla entry, for an update to Jeff Johnson's current release, but nobody has posted a definitive reason as to why that will not happen. But it does appear that there is no interest within Fedora to depend on Mr. Johnson for anything, much less an important piece of infrastructure, so Fedora appears unlikely to move to the newer releases.
What Greg DeKoenigsberg has said - backed up by Michael Tiemann - is that the time has come for Fedora and Red Hat to own up to what has happened and formalize the new status of RPM. The current situation, where RPM has been forked but nobody is saying so, will not lead to anything good in the long run. The new RPM - perhaps the "Red Hat Package Manager" yet again - needs to have its existence acknowledged and its maintainership made clear. Either that, or Red Hat and Fedora should acknowledge the current RPM maintainer and move toward rejoining with his version of the code. Until one of those things happen, there will continue to be a dark cloud of uncertainty surrounding a tool which is heavily depended upon by vast numbers of Linux users.
(See also: the the Fedora
rpm-devel wiki page, which lists features found in the current RPM
release but not in Fedora's version).
(Log in to post comments)
Who maintains RPM?
Posted Aug 22, 2006 22:44 UTC (Tue) by dskoll (subscriber, #1630) [Link]
As a developer, I find RPM to be a shockingly evil piece of software. There is precious little up-to-date documentation for creating .spec files, and there are hundreds of hidden and undocumented hacks, macros and tweaks. I don't know anyone who has written a .spec file from scratch. Everyone I know starts with an existing .spec as and example and then modifies it.
We also make .debs of our software, and while building .debs is also pretty arcane, at least there's lots of documentation and it's mostly up-to-date.
Who maintains RPM?
Posted Aug 22, 2006 22:50 UTC (Tue) by smoogen (subscriber, #97) [Link]
Tsk David.
I wrote a spec file from scratch for mimedefang of all things. You had already one by the time I got it to you though.. but I did write it from scratch.
Who maintains RPM?
Posted Aug 22, 2006 23:07 UTC (Tue) by smoogen (subscriber, #97) [Link]
There were supposed to be some :) at the end of the post.. but I seem to have forgotten them... so here they are
:) :).
Who maintains RPM?
Posted Aug 22, 2006 23:34 UTC (Tue) by bojan (subscriber, #14302) [Link]
> There is precious little up-to-date documentation for creating .spec files
http://fedora.redhat.com/docs/drafts/rpm-guide-en/
http://fedoraproject.org/wiki/Packaging/Guidelines
> Everyone I know starts with an existing .spec as and example and then modifies it.
Really shocking ;-)
Who maintains RPM?
Posted Aug 22, 2006 23:37 UTC (Tue) by dskoll (subscriber, #1630) [Link]
Hmm, I was unaware of the docs on the fedoraproject.org site. I'll have to take a closer look.
Thanks.
Who maintains RPM?
Posted Aug 23, 2006 8:51 UTC (Wed) by seyman (subscriber, #1172) [Link]
Hmm, I was unaware of the docs on the fedoraproject.org site. I'll have to take a closer look.In your defence, it would make more sense for this to be on rpm.org, which is a site that looks abandonned these days.
Who maintains RPM?
Posted Aug 22, 2006 23:40 UTC (Tue) by lovelace (guest, #278) [Link]
I don't know anyone who has written a .spec file from scratch. Everyone I know starts with an existing .spec as and example and then modifies it. I wrote many spec files from scratch while I worked at a company that maintained its own rpm based distribution. It's not that hard. It just take a little bit of practice.
Who maintains RPM?
Posted Aug 22, 2006 23:40 UTC (Tue) by lovelace (guest, #278) [Link]
Ugh. Parden my formatting in my previous comment. :-( The italics were supposed to be a quote, but then I forgot that I was in html and needed a paragraph tag. :-(
Who maintains RPM?
Posted Aug 23, 2006 8:57 UTC (Wed) by mihaim (guest, #40072) [Link]
RPM is not that evil. I agree that are lots of macros and tweaks but in 99% of the cases you don't need to get that deep with the spec.I wrote many of the specs for TFM/GNU Linux and also i patched rpm to finally implement --fetch. The patch was taken into consideration by Mr. Johnson and i think it got into rpm tree. Back to the point: writing .spec's is not that hard. Takes a little bit of practice.
Who maintains RPM?
Posted Aug 22, 2006 22:55 UTC (Tue) by smoogen (subscriber, #97) [Link]
Jon,
A very important correction to your article please.
> For the purposes of the people using distributions from Red Hat and SUSE,
> RPM is essentially unmaintained.
This is untrue for Red Hat (and probably SuSE.) For Red Hat, Paul Nasrat has been doing lots of work with RPM in the last year or so for Red Hat Enterprise and the porting/creation of patches to RPM in Fedora.
The reason for not upgrading in RPM for Red Hat Enterprise is pretty clear that the ABI/API for RHEL-3/4 {and SuSE 9) should be set in stone so that people can write RPMs and not have to redo syntax, logic in triggers and such.
The reason that it hasnt been upgraded in Fedora seems to have been that some of the changes in syntax, options in the 4.4.5 RPM has things that yum, mock, and apt would choke on for things like "alternatives" and other items. [I do not state this as fact however... but on hearsay from the yum original author.]
Who maintains RPM?
Posted Aug 23, 2006 1:59 UTC (Wed) by louie (guest, #3285) [Link]
SuSE also does (or at least did when I left there) fairly active development on their branch of RPM. So "Red Hat and SUSE's RPM development trees are internal, not public, and not coordinated centrally", or "no one uses jbj's branch of RPM", would both be accurate, but "RPM is unmaintained" is not accurate, as far as I can tell.
Who maintains RPM?
Posted Aug 23, 2006 2:57 UTC (Wed) by skvidal (guest, #3094) [Link]
Suse's branch is pretty close in terms of what they support to fedora rpm.
In short, we're all watching each other trying to figure out where to go next.
I believe that's referred to as some kind of standoff.
:)
-sv
Who maintains RPM?
Posted Aug 23, 2006 3:02 UTC (Wed) by skvidal (guest, #3094) [Link]
the problem with the soft dependencies is that we've got no defined semantic for handling them automatically. Additionally, we have no policy to keep someone from doing:
Enhances: glibc
and having their package pulled in EVERY time.
This, among other reasons, is why we wanted to stage in things like Suggests/Enhances - the soft deps.
We wanted to be able to know when those things would go in. And since they would have fairly far-reaching impact gracefully add them - probably as a major point release or at the very least not a minor.minor release.
I think it would be radical and exciting if rpm had:
1. a roadmap
2. a development cycle based on time or at least based on feature
3. some concept that some features break things or cause other havoc so they need to cycle them through in something other than point release.
-sv
Who maintains RPM?
Posted Aug 23, 2006 11:44 UTC (Wed) by n3npq (guest, #40075) [Link]
Not true.
The mechanism for soft dependencies in rpm sets a RPMSENSE_MISSINGOK bit which has
pre-defined semantics that the dependency is provided to depsolvers who are free
to do whatever they wish with the dependency including ignoring the dependency
entirely as rpmlib does.
So ignore
Enhances: glibc
in yum if you wish.
Or even better, fix the package that contains a bogus dependency.
Who maintains RPM?
Posted Sep 4, 2006 4:40 UTC (Mon) by hazelsct (guest, #3659) [Link]
> Or even better, fix the package that contains a bogus dependency.
That's a lot easier done in Debian, where the project controls all 17,000 packages, then in Fedora, where unofficial repositories contain a large fraction of the packages in common use.
Shining more light on the problem
Posted Aug 23, 2006 0:51 UTC (Wed) by dowdle (subscriber, #659) [Link]
Jon,
Thanks for the article. While the problem was public and there for all to see, by bringing it out as a feature article of LWN, chances that the situation will change for the better have increased.
It wouldn't be a bad idea to mention that rpm works well for most everyone most of the time... and that in the corner cases where something does go wrong, there is usually a lot of info to be found on how to fix the problem and/or avoid it in the future. Those admissions aren't an attempt to avoid resolving the situation.
I credit Red Hat for acknowledging the problem with a named individual... rather than the typical corporate anonymous insider comment.
Now we see the problem. We know the solution... we just have to make it happen.
I would like to comment in defense of Jeff Johnson. I think he was unnecessarily vilified... not really here but in various posts linked to in this article. Now, that doesn't mean I agreed with all of his comments, reasoning, or tactics... but what he didn't say was obvious... that with regards to that bug... he really didn't want to fix the issue and didn't want to admit it. If he wasn't being paid to fix it, and it worked well enough for him, and he was happy with it, he isn't a horrible person for not fixing the problem. It was just another opportunity for someone else to say that's not good enough for me, I'll fix it. It is sad that so much effort was put into nagging at him rather than someone just fixing it and submitting a patch. Sure, he egged people on by pretending there wasn't a problem... the but the axiom of "show me the code" always applies. Of course, that is easy for me to say since I'm not a programmer. :)
I would also like clarify that perhaps there should be some sort of group formed by the various distros that use rpm (not just Red Hat and/or Fedora) to maintain it. I would imagine that all of the various companies using rpm have someone assigned to work on rpm when needed... so having all of those people, across distros, work together seems like a no-brainer. Nothing too elaborate... just a commitment to work together, find problems... and hey... maybe even set a direction for the future... unless everyone just wants to adopt that new management system that was created by all of the former Red Hat folks. What was the name of that one again? I read up on it a while ago and it had so much lingo and so many layers and features, it was really above my head. How about an article about that one?? I ask the question rather than googling it, to give others an opportunity to add to this discussion.
Yes, Red Hat created RPM and it has worked well for a long time... but Red Hat set it free some time ago... and I think it should stay that way if at all possible... as long as it finds the way to continuing to work well for years to come... or a path to something better is forged for those using it.
This is just more evidence that Red Hat is suffering from PR shell shock... and they don't want to accidentally piss off the Slashdot hordes again by grabbing control back of something that they really wanted to free... like what happened with Fedora. Yeah, some people just can't grasp reality... and I think most of those folks go into politics.
Now off the beaten path... IMNSHO, Red Hat needs to merge Cluster Server, GFS, Directory Server, and Certificate Server... into RHEL AS/ES... and then reduce the price of RHEL... to somewhere around the cost of Mac OS X Server Unlimited... and/or SUSE Linux Enterprise Server. Really they do. Then I'd use RHEL everywhere... and CentOS wouldn't even cross my mind in some situations. Yes, all of their top 100 customers have deep, deep pockets and can afford their fairly close to reasonable existing price structure... but just think how many people would buy it if it was more affordable? Volume could make up for reduced margins. Really it could.
Shining more light on the problem
Posted Aug 23, 2006 2:05 UTC (Wed) by gdt (subscriber, #6284) [Link]
I credit Red Hat for acknowledging the problem with a named individual...
Well I don't. This wasn't the first episode -- pressing Ctrl+C when running RPM once upon a time corrupted the database too. We were a paying customer and submitted a bug report. A similar level of lack of ownership and vitriol was displayed by the developer.
This was a showstopper bug for a production billing system. His supervisor didn't appear to take any action. There seemed to be no automated escalation. There seemed to be no level of management that would act upon our complaints and escalate the issue to a more capable developer. The local Red Hat office advised us that they had no influence. The resolution dragged on and on and was eventually to prevent Ctrl+C having any effect upon RPM. Of course that meant that any runaway RPM process could only be stopped with kill -9, which would of course corrupt the database.
I can't think of any other software company that would have allowed this sort of behaviour from an employee for such an extended period of time. It doesn't surprise me at all that other RPM bugs struck similar issues.
It is sad that so much effort was put into nagging at him rather than someone just fixing it and submitting a patch.
No. If we wanted that we'd use Debian. We pay Red Hat so that they take ownership of problems. If a Fedora user reports a showstopper problem we expect it to be addressed before it effects our applications running on RHEL. That's why we're happy to have our payments for RHEL used to subsidise the Fedora distribution.
Red Hat software maintenance is often more expensive than Solaris, AIX or Cisco -- and they include hardware maintenance too. We expect a level of service which matches the scale of those payments.
Shining more light on the problem
Posted Aug 23, 2006 9:55 UTC (Wed) by kleptog (subscriber, #1183) [Link]
Ouch! If I got a corrupt database everytime I hit Ctrl-C while running dpkg, I'd be pretty pissed.
Dpkg may not be perfect, but it's never ever corrupted it's database on me, and I've beaten it pretty badly over the years.
Shining more light on the problem
Posted Aug 23, 2006 16:22 UTC (Wed) by dowdle (subscriber, #659) [Link]
That was a bug from long ago... and the rpm database could be repaired by using the rebuild flag. They fixed that the bug.
I'd rather not see this discussion digress into an rpm vs. dpkg thing.
Shining more light on the problem
Posted Aug 23, 2006 17:04 UTC (Wed) by anonymous21 (guest, #30106) [Link]
Let's correct that:
... the rpm database could be repaired (sometimes) by using the rebuild option...
RPM was always a fearful tool for me.
Although it has probably vastly improved since then. (redhat 6,7,8)
Mark
Shining more light on the problem
Posted Aug 23, 2006 16:19 UTC (Wed) by dowdle (subscriber, #659) [Link]
I'm confused. There needs to be some sort of timeline here.
RPM reporting on Red Hat's bugzilla was part of the confusion... as the open project was using the commercial vendor's bugzilla for bug tracking. Were bugs reported for the open project or for the vendor? Bugzilla *IS NOT* the Red Hat Support system and anyone using it for that is spinning their wheels.
When was Jeff Johnson working as a Red Hat employee and when was he NOT? Were his responses in bugzilla an official part of his Red Hat job or part of the open project?
See, lots of room for confusion.
Shining more light on the problem
Posted Aug 24, 2006 8:33 UTC (Thu) by hadess (subscriber, #24252) [Link]
[...] We were a paying customer and submitted a bug report. [...]
Bugzilla is not a support system. From the front page of the Red Hat Bugzilla:
Bugzilla is not an avenue for technical assistance or support, but simply a bug tracking system.
I think that makes it pretty clear.
Shining more light on the problem
Posted Aug 25, 2006 19:03 UTC (Fri) by Tet (subscriber, #5433) [Link]
I would like to comment in defense of Jeff Johnson. I think he was unnecessarily vilifiedAs the original submitter of the bug mentioned, I feel I should comment here. I gave Jeff the benefit of the doubt for a long time, until he proved utterly unable to listen to reason. You can bleat "Show me the code" as much as you like (and I'd even agree with you -- were it more of a problem for me, I'd almost certainly have written a patch myself by now), but a maintainer of a package as significant as RPM simply has to listen to bug reports from users, and take some appropriate action. Denying that the bug even exists is simply not acceptable.
Who maintains RPM?
Posted Aug 23, 2006 1:10 UTC (Wed) by drag (guest, #31333) [Link]
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.
Who maintains RPM?
Posted Aug 23, 2006 7:19 UTC (Wed) by rsidd (subscriber, #2582) [Link]
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 (subscriber, #33129) [Link]
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 (subscriber, #424) [Link]
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]
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 constitutionI'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]
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]
> 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
Who maintains RPM?
Posted Aug 23, 2006 3:43 UTC (Wed) by skvidal (guest, #3094) [Link]
A little light to add to things:
The thread about Jeff on the Fab list is partly about behavior on bugzilla and partly about issues interacting with him from various rpm maintainers in various distros.
Cruise through bug reports and the rpm-devel mailing list archives. There are a number of not-so-fun interactions about different patches.
This last week Jeff announced that he would be changing the license of rpm from gpl to lgpl:
https://lists.dulug.duke.edu/pipermail/rpm-devel/2006-Aug...
That seemed a bit odd to some of us.
The fedora project board has been discussing what to do about rpm in general over the last month. At the last meeting I was tasked to talk to the other stakeholders in rpm (the distros using it, other interested parties) and find out what other people thought. The goal was to form a consortium of people who want to help maintain and further development of rpm.
I talked to people at novell/suse, mandriva, openpkg and some other not-quite-distro but not-quite-unrelated parties.
The sentiments were similar:
we're not sure what's going on. we're watching everyone else to see what they do.
What I don't want to see happen with rpm is that it breaks down and fragments. I'd like to see everyone using roughly the same tree with a stable release cycle and development roadmap. This means getting all the people involved in a place where they're willing to talk and figure out what we ALL want to achieve.
We cannot do that with the current development "process" in place.
So that's what I know and what I've been doing to try and make this a bit more reasonable for everyone.
rpm is a crucial piece of infrastructure and I think it deserves a development process at least as robust and rigorous as gnome's.
thanks,
-sv
Who maintains RPM?
Posted Aug 23, 2006 4:15 UTC (Wed) by skvidal (guest, #3094) [Link]
As an addendum:1. I do not work for red hat nor do I speak for red hat
2. while I am on the fedora project board I do not speak for the board.
no one told me to say that I just thought it would be best to say it lest someone get confused.
:)
thanks,
-sv
RPM is not the only one
Posted Aug 23, 2006 7:40 UTC (Wed) by joey (guest, #328) [Link]
rpm is not the only peice of software that is a major component of many linux distributions but has no agreed-upon upstream maintainer, and thus effectively one fork per distro. Another such peice of software is cron.Vixie cron was last released in '93. In many distributions it's still used, but in eg, Debian, the package is the result of 13 years of patches on top of that release. The debian version number is 3.0pl1-96. That's ninty-six versions based on 3.0pl1. The Red Hat sub-version is in the fourtys. There's no standard version anymore, just this pile of patches, and other piles of patches in other distributions. If we're lucky, they at least share the same security fixes.
Another example is makedev, which was had its last upstream release in '98 and is at patchlevel 82 in Debian. Or netcat, last released in '96, patchlevel 32 in Debian, and a fork/rewrite at netcat.sourceforge.net. Or xgalaga, whose upstream author has fallen off the net and last released it in '98. The Debian package, which I maintain, is at patchlevel 37, and seeme to be the only place a lot of people can find to send patches to. But I don't want to be its upstream maintainer.
This is the kind of thing that makes me gibber in horror when people at Ubuntu talk about Debian and other distros being part of an "ecosystem of software". I don't want to be part of an ecosystem; I'd rather be part of something that works not something that muddles through via massive trial-and-error and redundancy. Biomass is another word for "shit".
But I digress..
The most productive thing I've seen done to try to address this general problem is the Unmaintained Free Software wiki, which tries to track this software and find new maintainers. That has managed to match up some software with interested people (though it failed with xgalaga), but I think it actually works less well for big and important software that ends up forked and maintained separately by the major linux distributions.
I, myself, am beginning to use the degree of divergence from upstream as an indicator of how well a distribution maintains a given peice of software, with more divergence == bad. A distro that's doing a good job will a) get their patches integrated upstream and b) should work with other distros to find a new developer if upstream goes missing or insane.This is the inverse of what people might naively consider a good metric of how much work a distro is doing, but I think it leads to better software in the long run.
PS: My limited interaction with Jeff when I used to maintain rpm for Debian was fairly problem-free.
PPS: I've written hundreds of spec files compeltly by hand, a dozen years ago. :-)
RPM is not the only one
Posted Aug 23, 2006 7:59 UTC (Wed) by nowster (subscriber, #67) [Link]
rpm is not the only peice of software that is a major component of many linux distributions but has no agreed-upon upstream maintainer, and thus effectively one fork per distro. Another such peice of software is cron.
There are great problems with communicating with RedHat. Nowadays, there appears to be no named maintainer for many important packages, and using the bugzilla isn't always appropriate, especially with security-related problems.
As one distro's maintainer of several packages based on RedHat/Fedora upstream sources, this is incredibly frustrating. Finding new upstream versions is often a matter of stumbling across them by accident, rather than having a stable location to find them. I used to have read-only CVS pull access to one upstream source but that disappeared without notice one day, and I got bounces from the email address of the person I'd originally been in contact with about it.
Like joey, I get people sending me patches in frustration.
RPM is not the only one
Posted Aug 23, 2006 11:36 UTC (Wed) by rahulsundaram (subscriber, #21946) [Link]
You are right about bugzilla not being the right place to handle security issues in many cases. The recommended procedure for Fedora and RHEL respectively are
http://fedoraproject.org/wiki/Security
http://www.redhat.com/security/team/contact/
cvs versions of all of Fedora is available at
If you have any other issues, feel free to mail me @fedoraproject.org
RPM is not the only one
Posted Aug 24, 2006 9:27 UTC (Thu) by nowster (subscriber, #67) [Link]
cvs versions of all of Fedora is available at...Browsing the CVS, no source code is visible at any level, only the occasional Makefile or patch file. I'd email you directly about this, but you didn't give your full email address.
RPM is not the only one
Posted Aug 24, 2006 20:53 UTC (Thu) by bojan (subscriber, #14302) [Link]
See if this helps:
RPM is not the only one
Posted Aug 23, 2006 8:24 UTC (Wed) by rsidd (subscriber, #2582) [Link]
Xgalaga doesn't matter -- if there are no maintainers, let it die. Cron, makedev, etc should be part of the "base system" of any Unix-like OS, and if there is no reliable upstream version, well, you need to maintain it yourself... If Debian's version, or Red Hat's version, earns respect in being well-maintained, others can use it and it may become the "canonical" version.The BSDs do this right, by keeping all essential Unix programs in their base system and taking full responsibility for them. And all the BSDs are much smaller projects than Debian; none of them (except Apple) are corporate entities like Red Hat. If they can do it, Linux distros can too.
You may argue that this means a "fork", as FreeBSD's cron differs from NetBSD's and so on. But in cases where there is no upstream maintainer, this is unavoidable. Where an upstream maintainer does exist (gcc, binutils, openssh) the BSDs resynchronise with the upstream source periodically, and, of course, feed their own bugfixes upstream.
RPM is not the only one
Posted Aug 23, 2006 9:05 UTC (Wed) by MathFox (guest, #6104) [Link]
I agree with what you say; a distributor has to ensure that essential packages are sufficiently maintained. This may mean that she has to bite the bullet and write her own security patches.There are some problems with distributor maintained packages. There's the "duplication of effort" issue where each distributor writes her own patches. The "selection of the fittest patch" has halted. The base versions are different, patches can not be easily ported, patches are not communicated and the "Beneficial Dictator" has left his post. The program as such will wither without central maintainer, but it is certainly thinkable that one of the distributor's forks will become the leading variant.
Should we cry about this situation? No, it's evolution in action and as long as the sources are available there is room for someone to pick up. We should get worried when community distributions like Debian and Gentoo start withering.
RPM is not the only one
Posted Aug 23, 2006 9:40 UTC (Wed) by Frej (guest, #4165) [Link]
Offtopic....Well cron sucks, it does not expect your computer to be turned off.
It did make sense then, now it doens't.
Apple fixed the mess with launchd, and now the source is there with a apache 2.0 license.
RPM is not the only one
Posted Aug 23, 2006 9:59 UTC (Wed) by kleptog (subscriber, #1183) [Link]
And so the world created anacron, and all was well again :)
RPM is not the only one
Posted Aug 24, 2006 19:15 UTC (Thu) by vmole (guest, #111) [Link]
Unless, of course, you want support for individual crontabs.
RPM is not the only one
Posted Aug 23, 2006 10:44 UTC (Wed) by job (guest, #670) [Link]
I like fcron.
I've heard others praise dcron, too.
RPM is not the only one
Posted Aug 24, 2006 19:22 UTC (Thu) by vmole (guest, #111) [Link]
Unfortunately, neither is a drop-in replacement for Vixie cron. There's just too much history behind vixie cron to replace it with anything that doesn't support all the weird variations of crontab syntax. (Obviously, I'm talking about the general case, done on a distribution level. Individual sysadmins can do what they want, and that's fine.)
What should really happen is to develop a cron-like system with equivalent capabilities but a sane syntax, the ability to control things like "what happens when a jobbed is skipped" or "what if the previous invocation is still running", etc. etc. etc. Instead of reading crontabs, write a converter . It can fail on the corner cases so long as it tells you it's done so.
RPM is not the only one
Posted Aug 25, 2006 15:57 UTC (Fri) by nix (subscriber, #2304) [Link]
Many of those weird variations are hardly ever used. @reboot (I think it is) was broken in Debian cron for *years* before anyone reported it...
RPM is not the only one
Posted Aug 31, 2006 19:50 UTC (Thu) by vmole (guest, #111) [Link]
But the screaming that occurred when somebody noticed! It was suddenly ABSOLUTELY VITAL and we COULD NOT LIVE WITHOUT IT!!!
But I'm not bitter.
Steve, former Debian cron maintainer.
RPM is not the only one
Posted Aug 30, 2016 17:16 UTC (Tue) by Wol (subscriber, #4433) [Link]
Is that called systemd?
(lighting blue touch paper and retiring at full speed to a safe distance ... :-)
Cheers,
Wol
Upstart instead of launchd
Posted Sep 4, 2006 17:28 UTC (Mon) by ttfkam (guest, #29791) [Link]
While in general I very much like the direction Apple has taken with its operating system, and while I think that launchd is a tremendous improvement over initd, I think Upstart is a better solution to the problem -- especially for Linux systems.
Bear in mind that I own or have owned a G3 iBook, a G4 Powerbook, and an Intel-based MacBook Pro, so I'm by no means biased against Apple products.
However, this description page for Upstart accurately reflects why I think it's better than launchd (or initd-ng for that matter).
Event-driven instead of polling loops, dynamically discoverable dependencies instead of explicitly specified dependencies, compatible and resiliant with a wider variety of hardware and software configurations, and more.
I realize that launchd is getting all the press, but that doesn't automatically make it the best choice. For OS X, where the hardware and software are almost completely controlled by a single source, launchd makes sense -- and once again, is a tremendous improvement over initd. For Linux, I think Upstart best fits the bill.
RPM is not the only one
Posted Aug 25, 2006 19:22 UTC (Fri) by kreutzm (guest, #4700) [Link]
Well, I don't know about NetBSD and FreeBSD, but OpenBSD is *proud* not to feed their bugfixes upstream, instead claiming: "We fixed this a long time ago" when someone else fixes it upstream.
RPM is not the only one
Posted Aug 23, 2006 18:17 UTC (Wed) by dberkholz (guest, #23346) [Link]
What about ftp://ftp.isc.org/isc/cron/ ? I see a 4.1 there that's released in 2004.
Who maintains RPM?
Posted Aug 23, 2006 15:22 UTC (Wed) by stock (guest, #5849) [Link]
i would say that mandrake/mandriva did a tremendous job of their own.Their (S)RPM system never gave me problems with them. everything works
like expected and reported. Here's the Mandriva wiki's on RPM :
Mandriva RPM HOWTO
http://qa.mandriva.com/twiki/bin/view/Main/RpmHowTo
URPMI resources page
http://qa.mandriva.com/twiki/bin/view/Main/UrpmiResources
Who maintains RPM?
Posted Aug 23, 2006 17:11 UTC (Wed) by emkey (guest, #144) [Link]
RedHat has been making some much needed improvements in the RHEL 4 version of rpm at least. A couple of years back Mr. Johnson apparently decided it was a good idea to remove all DB file locking from RPM rather then fix the limited locking that existed at the time. This was needless to say a rather bad idea and led to lots of accidental corruption. RedHat has fixed this issue. They've also been very responsive to other suggestions for fixes and changes. For instance until recently there was no equivalent for --ignoresize when trying to remove rpm's. Why did this matter? Because until recently rpm insisted on stat'ing every single mounted filesystem any time it did an add or remove. It is not out of the ordinary to have one or more remote filesystems in a less then happy state if you're environment is large and complex. Having your rpm remove hang for long periods of time was very frustrating.
In summary, RedHat has been doing a much better job recently on the RPM front. Now they need to formalize things and take back control. Based on past experience I wouldn't touch anything Mr. Johnson worked on with a fifty foot pole.
Who maintains RPM?
Posted Aug 23, 2006 19:44 UTC (Wed) by n3npq (guest, #40075) [Link]
Guess who built rpm for RHEL4?
Who maintains RPM?
Posted Aug 23, 2006 21:00 UTC (Wed) by emkey (guest, #144) [Link]
Well, we're up to update four? on RHEL 4 at this point so the more important question is who built it for the past couple of updates.
Who maintains RPM?
Posted Aug 24, 2006 1:33 UTC (Thu) by dankamongmen (subscriber, #35141) [Link]
Thanks very much for an interesting and informative story on a topic I, as a Debian elitist, would otherwise have likely missed in toto. It's articles like this that keep me subscribing.
Who maintains RPM?
Posted Aug 24, 2006 7:50 UTC (Thu) by lamikr (guest, #2289) [Link]
Is there something technicallly advantageous in deb packages compared to rpm packages or other way around?
Like does either of these systems have superiour dependency handling tools for the package developers, or better syntax for handling those dependencies.
Or are these tools just offering about the same level of functionality while being incompatible with each others and requiring that the app packagers need to handle both of the syntaxes. In that case maybe it would go a good idea from fedora to jump also to jump to use debian packages by default. At least for the end users that could be a win in the long run.
Who maintains RPM?
Posted Aug 24, 2006 8:24 UTC (Thu) by seyman (subscriber, #1172) [Link]
Is there something technicallly advantageous in deb packages compared to rpm packages or other way around?Joey has a very complete page on the differences between dpkg and rpm
Note that rpm now handles recommendations and suggestions but Fedora and Suse aren't picking up the upstream version that does this.
Who maintains RPM? A defense of Jeff Johnson
Posted Aug 24, 2006 20:29 UTC (Thu) by sarnold (guest, #39590) [Link]
I've known Jeff for years; while I've had my fair share of arguments with RPM (and I've lost many :), I have always enjoyed discussing my problems with Jeff. He doesn't always like my proposed solutions to problems, but he has always been willing to talk about what problem I'm trying to solve so that he can help find a solution that works better for more people.
Mistakes were made in RPM's development, but blaming every deficiency of RPM on Jeff is also a mistake.
Who maintains RPM? A defense of Jeff Johnson
Posted Sep 2, 2006 2:01 UTC (Sat) by dag- (guest, #30207) [Link]
I agree with sarnold on this.
Jeff's sarcasm and sometimes rude comments seems to have grown over time and if a company is unable to correct this for a 2 years timespan the problem is related to lack of communication or lack of resolution inside the team/company and not entirely Jeff's responsibility.
I wouldn't be surprised if discontent, burn-out or lack of empowerment are the cause of abusive language and these are symptoms that are easy to detect and act upon. (People-skills!)
AFAICS Jeff is still maintaining RPM in good faith (despite recent public sarcasm towards Red Hat/Fedora). Red Hat however seems to favor to fork the project. This inability or unwillingness to reconciliate is an unfortunate escalation of something that is in essence fixable by good communication and mutual respect.
I hope a fork can be avoided by fixing what is broken. (and I'm not talking about RPM :-))
PS Backporting Jeff's work without credit for the work (Jeff already made statements about that on bugzilla) is not a good way forward. Ignoring him will also not fix the issues at heart.
PS2 Also the bugzilla entry is NOT about database corruption. You can have the same symptoms by just removing files on your disk. RPM will list them as *missing*, but of course the rpm database will still list them. That's 'work-as-designed'. You can argue if that is expected behaviour during installation, but this is not database corruption. If you take this in consideration, Jeff's comments make much more sense and less rude. KainX's comments clear this up, but the author fails to make this clear. The bug-report is basicly wrong. It does not condone the rude remarks in both directions.
Who maintains RPM?
Posted Sep 1, 2016 23:25 UTC (Thu) by johannbg (guest, #65743) [Link]
I cant stop rofl and I cant believe I somehow missed this golden nugget from Red Hat all those years I spent crawling through bz.rh and I would love to hear the reason why Suse never updated it. Is it because they are just using rebuild components from Red Hat or was it something else and if so what exactly.