Re: Building rpms in mock

Zenon Panoussis writes:

>
> I put some work in this. It got quite messy. Ugly, in fact.
> The documentation of rpm macros and their workings is
> absolutely superficial and sparse. The same goes for man mock.
> Look at this:
>
> --with=OPTION
>     Enable configure OPTION for build. This option may be used multiple  
> times. For example:
>
>     --with=extra_cheese
>
> It would only have costed 47 extra bytes to write explicitly
> that "--with=OPTION does not accept option arguments", but
> instead you're left to find that out by trial and error. So
> --with=extra_cheese works, but --with-cheese=mozzarella does
> not, and you have to use --define 'cheese mozzarella' instead.

That's why I don't like the --with options.  I found that use --define is  
less pain. The syntax is slightly more difficult, but there's no ambiguity.

> Anyway, I got it working on the level of the specfile, but
> then I run into a problem in the source code. A specfile diff
> follows below. Check the comment between %install and %{__install}.

There are a bunch of chowns and chgrps in Makefile.am, but their failures  
should be ignored (but there will still be a visible error message).

Anyway:

I don't have any immediate plans to add more configure options, but still I  
don't like how this approach ends up duplicating the list of options in the  
spec file, and going forward this requires the spec file to be updated to  
reflect any changes to the configure script options.

This is why I believe it's less of a headache just to have a single define,  
use that --define, and pass through any set of options via the define to  
%configure. rpm packages really are not meant to offer custom configuration  
options, but to build a known package that's configured in a known way, for  
a distribution. A default package build is going to be the case 99% of the  
time, so putting in a long list of options in a spec file looks like a lot  
of effort for little gain.

I think that right now it's more important to put in safeguards to prevent  
updating to an incompatible newer version that was accidentally built with a  
different user or group id. I have some ideas on how to make that happen.  
I'm going to try the following:

Explicitly define mailuser and mailgroup in the spec file, as defines, and  
they can be overriden. The mailuser and mailgroup defines get passed through  
as the corresponding options to configure.

An additional define, passed through to configure, to be used as a dumping  
ground for all other options.

A courier-authlib-config-%{mailuser}-%{mailgroup} empty subpackage. So,  
it'll be courier-authlib-config-daemon-daemon for me, and courier-authlib- 
config-courier-courier for you. The name is ugly, but who cares. Both  
courier-authlib, and all other packages will get a dependency on this  
subpackage. I think this can be done in a way that'll work even for the old  
version of rpm in centos 7.

With courier-authlib-config-%{mailuser}-%{mailgroup} being a discrete  
subpackage then it's a simple matter to make sure that they all conflict  
with each other. A very simple matter. Now, any attempt to upgrade to a  
differently-configured build is going to fail a dependency check.

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

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

iHUEABYKAB0WIQRupkKLJP96aW75pIOKYPgoojZS4gUCZYbfSgAKCRCKYPgoojZS
4jUfAP9Y7aIf5NJ3xVT0xYVTDVkxnBObDLa+JVMLQVvzPFJzQwEAqG4UvTHGU7/W
PiPVJADhzGTqiPISygyXrEHQV7HBsgg=
=gziE
-----END PGP SIGNATURE-----