Hi,
An alternative could be to get rid of these %bcond and _with_xxxx
constructs: it's easy to disable the macros %with and %without. It's
also easy to check the use of _with_xxxx or _without_xxxxx and forbid that.
Then this let's the ability to define our own model, without having to
take care of the past:
* in project config, we could use macros to enable or disable features:
%feature_enable myfeature
or
%feature_disable myfeature
* then in spec files:
%if %{isfeature_enabled myfeature} ...
or
%if %{isfeature_disabled myfeature} ...
But I also see two problems with this approach:
* compatibility with RPM (foreign spec files)
* a lot of git trees should be updated ...
For the moment, it's probably safe to document the %bcond construct and
try to avoid the usage of _with_xxxx macros directly.
BR
--
Stéphane Desneux
Intel OTC - Vannes/FR
gpg:1CA35726/DFA9B0232EF80493AF2891FA24E3A2841CA35726
On 06/11/2014 17:58, Patrick Ohly wrote:
> On Thu, 2014-11-06 at 17:18 +0100, Dominig ar Foll wrote:
>> Best practice is to defined option variable via %bcond as it allows to
>> read the default options in an easy way and they can be changed in the
>> rpm command line and add a comment in the spec file.
>
> So bcond is staying as the recommended approach?
>
> I remember an Intel-internal discussion where it was pointed out that
> when inheriting from a project in OBS, the choice of the parent project
> for enabling or disabling something cannot be overridden anymore when
> using bcond.
>
> Ed Bartosh then proposed to use simple macros instead of bconds. Instead
> of:
> %if %{with pulseaudio_samsung_policy}
>
> the spec file would use:
> %if 0%{?_with_pulseaudio_samsung_policy}
>
> Is that proposal dead?
>
>> For more info of rpm behaviour see :
>> https://en.opensuse.org/openSUSE:Build_Service_prjconf#Macros
>
> For Tizen, https://wiki.tizen.org/wiki/Packaging/Guidelines is the only
> (?!) page we have that explains what a spec file for Tizen should look
> like.
>
> Unfortunately a lot of information is missing:
> * bconds not mentioned at all
> * no list of recommended and/or available macros
>
> For example, how is one supposed to know that %cmake is better than just
> cmake, or that %{_docdir}/.. should better be %{_datadir}/doc?
>
> I would update the page, except that I don't know the answers. Who does?
>
> Regarding bconds or macros (whatever we use), we should maintain a list
> of them in the Wiki. I volunteer to populate the list by grepping
> existing .spec files, but first we should clarify what the desired
> approach is.
>
_______________________________________________
Dev mailing list
[email protected]
https://lists.tizen.org/listinfo/dev
