Re: Building rpms in mock

Zenon Panoussis writes:

> The more I think about it, the more I think it would make
> a lot of sense to ask for a statically allocated uid:gid
> for courier and fix the user:group to that. It would have
> the benefit of all rpm installations being identical in
> this respect and smoothly upgradable without breakages
> such as a daemon:daemon upgrade of a courier:courier
> installation or vice versa not starting because all the
> certificates in /usr/lib/courier/share/ are chmod 600 to
> the wrong user:group.
>
> https://docs.fedoraproject.org/en-US/packaging-guidelines/UsersAndGroups/

I gave this some thought.

It's beyond dispute that a statically allocated uid:gid is, in general, the  
right solution. But that's going to seriously muck things up for everyone  
who already jumped in the boat and is running Courier as mailuser:mailgroup.

As long as they rebuild and update directly, on the live system, they'll be  
fine. courier-authlib's configure will find the existing one, and use the  
same mail user and group names that the existing installation does.

But if someone's building the packages in mock, the mock chroot will now  
have courier uid and gid in it, and the updated courier-authlib package gets  
built with that. Then it upgrades an existing package which was build with  
mailuser/mailgroup. The binaries will be ok. All configuration files and  
runtime directories and files are now completely broken. That's going to  
seriously mess things up.

I should find a way to prevent that from happening. This is notwithstanding  
on what the final outcome here will be. Statically allocated uid:gid, or  
not, I'm going to muck around with the courier-authlib rpm to have its %pre  
look and check for an existing package binary and see if it has a different  
uid:gid, and if so abort.

_______________________________________________
courier-users mailing list
[email protected]
Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users

-----BEGIN PGP SIGNATURE-----

iHUEABYKAB0WIQRupkKLJP96aW75pIOKYPgoojZS4gUCZYYrxQAKCRCKYPgoojZS
4ozqAQDTGFQapw5Eq2j7o+w8PKWoHn6JW7grXxyyq8ywgPOXNwEAkDwicT7JjQ6A
zA0ypiI1xng9v+sXqgM9w4AhCcGSGwA=
=skIh
-----END PGP SIGNATURE-----