Bill Crawford wrote: Package setup can't use post scriptlet (ok, maybe can use lua ... but it's not likely to have it there) - due to dependencies. I did quick&dirty way in rawhide - removing the most useless .rpmnew files in postun section - but user will still receive warnings about creating those files. AFAIK there is no other way at the moment (I requested RFE http://www.rpm.org/ticket/6 to have nowarn config file option) - please let me know if you know some way how to not bother users with useless .rpmnew file, but do not replace their files on update (as it would have horrible consequences in the case of file like /etc/passwd and/or /etc/shadow. Just for completeness - now it works the way that user/group added to default set of user/groups is created in post section of the ALL packages which actually need it for 2 Fedora releases. Worth of improvement, but don't know how to handle it better way for updates. Greetings, Ondřej Vašík

Ondřej Vašík wrote: Ah... given that users should be running as a normal (!root) account created at install time, isn't it *guaranteed impossible* to update /etc/passwd by replacing the old unmodified file with the new? Here's a pie-in-the-sky idea... store configs as deltas (since at least ~2-4 releases back), write the .rpmnew as always, and notify the user to run a merge tool after the transaction completes. No more diffing and merging by hand, except in the face of merge conflicts... -- Matthew Please do not quote my e-mail address unobfuscated in message bodies. -- Microsoft has become the next IBM; a dinosaur struggling to survive in the age of more able-to-adapt mammals (FLOSS). It remains to be seen if they'll be able to adapt before they go extinct.

Matthew Woehlke wrote: Yep, you could not replace /etc/passwd (and /etc/group, /etc/shadow, /etc/gshadow) file as it always differs from the file installed by setup (new users/groups, passwords ... ). But you need those files for installation - so they have to be in filelist and they have to be in rpm. AFAIK there is no option to ignore files completely in update, so .rpmnew are created although is always completely useless (unless you have some script to add missing users/groups from that .rpmnew file). I guess we can't expect user to run some merge tool after transaction. It has to be automated somehow. Maybe some separate file with default users/groups (like existing uidgid file) and something (?cron job) to periodically check it, if those users/groups do exist on system? Greetings, Ondřej Vašík

Ondřej Vašík wrote: I am confused, shouldn't the .rpmnew only get created if the version in the rpm has changed from what was in the last "successfully installed" rpm? IOW I should be able to install 1000 updates to the rpm with /etc/passwd, but as long as the /etc/passwd in the rpm is the same I should never see a .rpmnew. (Okay, the changed hashes throw a wrench in this, but that's another discussion that has already happened.) Why not? We already expect them to do something with the .rpmnew. Why not make "something" easier to do? Automated, unreviewed updates of config files are dangerous :-). It's technically possible (you could run the merge tool automatically) but I don't think it's a good idea. /etc/passwd is actually a case where automatic merge is probably fine for additions (removal is more dangerous, of course), but I'm thinking to apply this to config files in general. -- Matthew Please do not quote my e-mail address unobfuscated in message bodies. -- Microsoft has become the next IBM; a dinosaur struggling to survive in the age of more able-to-adapt mammals (FLOSS). It remains to be seen if they'll be able to adapt before they go extinct.

Jon Masters (jcm(a)redhat.com) said: rpm already has code to avoid making them when they're useless. It's just being defeated by the sha256 code for the first upgrade to rawhide/F11. Bill

On Wed, 2009-03-11 at 17:53 -0400, Bill Nottingham wrote: Yeah, this I know. But when would they be useful for the average user, if they'll never know they're "missing" a default user? Didn't we already say all additions should happen via scriplets anyway? If that's the case then only advanced users would know what these additional files were being created for and so think to add any additional users. Jon.

On Wed, 2009-03-11 at 17:53 -0400, Bill Nottingham wrote: So why aren't we putting both old and new hashes in the .rpm, for at least the duration of F11, so that we don't have this problem? RPM could then fall back on the old hashes for the purpose of detecting file modification if that's all that's in the existing RPM db.