On Fri, 2014-11-07 at 09:10 +0200, Ylinen, Mikko wrote:
>
>
> On Thu, Nov 6, 2014 at 6:58 PM, Patrick Ohly <[email protected]>
> 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?
>
>
> Do you see any benefits with this over what Dominig was proposing?
My understanding is that Dominig proposes to use bcond and "if %{with
<condname>}" and that this has the problem of not being overrideable in
OBS sub-projects, whereas Ed's proposal allows that. Is that correct?
I don't have any preference myself.
> * 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?
>
>
> That's slightly off topic and also something we cannot fully control
> because
> many of the macros are coming from upstream projects directly:
>
>
> root@ivi_box:~# rpm -q --whatprovides /etc/rpm/*
> cmake-2.8.11.2-5.1.i686
> file /etc/rpm/macros.imgcreate is not owned by any package
> perl-5.16.3-6.6.i686
> prelink-20111012-4.1.i686
> python-2.7.8-5.4.i686
> shared-mime-info-1.0-4.1.i686
> systemd-212-1.1.i686
Then a collection of pointers to the relevant documentation would help.
As it stands today, some novice packager (and quite frankly, most likely
developers packaging their own software for Tizen will be novice
packagers) looking at Tizen packaging instructions will not even know
that we have these macros in Tizen.
> There's only one issue I'm seeing: the RPM path macros are not
> following
> the tizen-platform-config data (or vice versa).
I'm not sure I follow here. Using the specific example above, is
%{_docdir} defined correctly in Tizen or should .spec files rather use
%{_datadir}/doc instead?
The murphy.spec change by Ronan makes that change, but there's no
explanation in the commit message and nothing in the Tizen wiki that
could serve as background information.
--
Best Regards, Patrick Ohly
The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.
_______________________________________________
Dev mailing list
[email protected]
https://lists.tizen.org/listinfo/dev
