Exactly. RPM's users are RPM's customers. RPM should try to serve them well, and this includes putting the documentatin for RPM in RPM's own documentation.
RPM is an open source package. Anyone is capable of jumping in and supplying documentation; the basic policy has always been "patches gleefully accepted". Furthermore, the only one you have any right to complain too about lack of documentation is: a) The distro vendor of which you pay for a support contract. b) Yourself. a) because if you did pay you are there customer. b) because this is open source and a community development model is what open source software is based on. Most of the developers of rpm, Jeff being the principal one, do not get payed by you to support them so you technically are not our customer. On the other hand I would be happy for you to be our peer and submit patches to document the things that you feel sorely need documenting (actually I do not diagree with you that they need documenting, but those of us who work on rpm typically work on the things that we care about and our employers care about...Jeff is honestly the only one that I know who does this out pure insane love for the application). OTOH if you wish a more traditional customer-vendor relationship then this is not the proper forum. That would be through RedHat's pay for support or the vendor of your choice.
>> OK, though Packages is too large to save every day, and just keeping the >> last one would mean that the sysadmin would need to notice the problem >> before that last good copy of Packages was overwritten. (I have an RPM >> database instance that has corruption but functioned normally most of the >> time, though not during an Anacoda upgrade to FC6. See RH BZ 215127.) It >> would seem that it would be better to only save good copies of the Packages >> file, and to report to a responsible sysadmin that there is an issue (if >> only there were such a sysdamin for most systems). I don't know how to do >> that with "rpm --rebuilddb", but I do know how to do that with "rpm >> --verifydb". >> > >Too large is a different problem, try "man rdiff" if you want an easy >incremental >backup. I see rdiff is in extras. I see it uses rsync. Possibly I will add that capability to my rpm_verifydb package. >> /No one/ saves a copy of Packages, as such an implementation detail is >> RPM's responsibility, and it does not do it. Don't blame the users for >> omissions! > >We disagree. If you want to protect your data, you need to take precautions. It disapoints me that you think it is not RPM's responsibility to protect its database.
Thats not what he saying. If you know Jeff you would know that he wishes to harden the database, what your missing is that its not his or any open source developer in the purest sense to see to the integrity of your data. If system go bad in the field where I work, my management comes to me, and then I figure out what went wrong, and try to make it not happen again. I do not point fingers because the systems integrity was my responsibility. Could rpm be configured to backup its data automatically based on some event, or could one produce script to do this on a timely basis. Sure. But I think the key is that we are in the area of policy here, and by default I probably don't want rpm databases being backed up everytime a write transaction occurs against them (I don't know about others). That being said, patches are gleefully accepted if you want to provide the mechanism such that the policy can be turned on. Or perhaps it does not need to be part of rpm proper all. Maybe just provide a package that supplies a cron job? Either way, a little coding on your side goes a long way. Cheers...james _______________________________________________ Rpm-list mailing list Rpm-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/rpm-list
