> a) change rpm to do all the work itself, and probably make this an > option you can override with a either your environment/macros or some > flag in the package -- the rules there get complicated quickly... This definitely gets you into a dicey area, doing this automatically in rpm. You certainly don't want it done for config files, but one should be at least moderately afraid of linking together two files that the user winds up modifying one of and not expecting to have modified the other. > or b) make it possible and safe to query the rpm db from a %post. I don't really know what the issues with this are. or c) do it in a separate pass later for those who care. This has the nice property that noone gets it who didn't ask for it, and so the a) quagmire of options is only a burden to those who want to deal with it. Not being built in to rpm or any such thing, it also has the nice property that whoever cares can go off and do it on their own, put it in Extras and have users love it and clamor for it in Core, rather than arguing in the abstract about whether it's worth doing. Doing this as the occasional cron job is pretty reasonable (if you care to do it at all). I mean, my frickin' awk script only takes a few minutes for 1917 installed rpms, so a real implementation in C using rpmlib directly should be pretty quick. The other wrinkle about doing this is the file attributes. Pretty much all the copies of COPYING have the same owner and permissions, but each one has a different modtime. (If files differ in attributes other than modtime, you shouldn't merge them into a single inode anyway.) To make rpm -V happy, the tool would have to update the rpmdb to make modtimes in the entries for duplicate names all match. This won't fix rpm -Vp complaints. For that, we would have to harmonize all the rpm contents across the distribution. For example, the tree-composing crapola could find the duplicates and tweak all the modtimes in the rpms to match. This seems like a pretty ludicrous amount of effort for the benefit it has. -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx http://www.redhat.com/mailman/listinfo/fedora-devel-list
