On Tue, Dec 1, 2015 at 11:40 PM, Peter Linnell wrote:

On Wed, 2 Dec 2015 06:27:51 +0300 Andrei Borzenkov wrote:

...

02.12.2015 02:56, Greg Freemyer пишет:

...

I decided to give Leap a try.

My main use case for production is a python app. The app is in OBS, but not in Leap. (I may be the only user, so it is not a big loss.)

In trying to get it going I find that python-protobuf is not in Leap either.

Now that surprises me. python-protobuf has been in openSUSE since at least 13.1 as a sub-project of protobuf.

The Leap protobuf specfile is at: https://build.opensuse.org/package/view_file/openSUSE:Leap:42.1/protobuf/pro...

Looking at the specfile for protobuf it says:

%if 0%{?suse_version} > 1210 && 0%{?suse_version} != 1315 %bcond_without protobuf_python %else %bcond_with protobuf_python %endif

I don't recall coming across bcond before, but that logic seems totally backwards to me. I gather that the suse_version being 1315 in Leap causes the python binding subproject not to be built.

questions:

- if I hard code "%bcond_without protobuf_python" then the python bindings subproject is built. In plain english, what does %bcond_without mean?

It adds "--without protobuf_python" argument support to rpmbuild command line. It does *not* itself affect whether it is built or not - somewhere else SPEC must check condition (with_protobuf_python in this case) and behave accordingly.

http://www.rpm.org/wiki/PackagerDocs/ConditionalBuilds

Greg,

I did a little digging and it seems Leap should have the python bindings, but somehow they did not get inserted into the Leap repo. If you look at the -devel project they are built and published.

So, to get them in the distro a maintenance SR is needed. I do not maintain that repo, otherwise I'd fix it myself.

http://download.opensuse.org/repositories/devel:/tools:/building/openSUSE_Le... has it

http://download.opensuse.org/distribution/leap/42.1/repo/oss/suse/x86_64/ does not

This took a while to get to my inbox, but I agree the devel project is correct. I've installed it in my Leap test VM and run some tests of python-protobuf. Thanks Greg -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

On Wed, Dec 2, 2015 at 6:44 AM, Dominique Leuenberger / DimStar wrote:

In any case, I'd file a bug so it can be properly tracked.. Submitting the Factory version should be good enough, if that's indeed the only difference.

http://bugzilla.suse.com/show_bug.cgi?id=957472 Greg -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

Note that with:

%bcond_with protobuf_python

no python binding subpackage is built.

bcond_with => conditionally build WITH support - condition being: specified using --with on the command line (or prj conf overrides)

While with:

%bcond_without protobuf_python

bcond_without ==> conditionally build WITHOUT support - condition, as above. As they are nicely if'ed, only one should be ever used to declare the default behaviou

Is this a specific double negative logic implementation in protobuf.spec, or is bcond always used with a double negative type logic.

bcond_* is generally misunderstood. *_with does not mean DEFAULT WITH, but on CONDITIONALLY_WITH (as said: conditions can come from CLI, see osc build --with/--without) or could be overruled by prjconf in OBS directly) It's messy - but once you get your head around it it's not that bad anymore. Cheers, Dominique -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

On Wed, Dec 2, 2015 at 12:21 PM, Dominique Leuenberger / DimStar wrote:

...

...

Note that with:

%bcond_with protobuf_python

no python binding subpackage is built.

bcond_with => conditionally build WITH support - condition being: specified using --with on the command line (or prj conf overrides)

...

While with:

%bcond_without protobuf_python bcond_without ==> conditionally build WITHOUT support - condition, as above.

As they are nicely if'ed, only one should be ever used to declare the default behaviou

...

Is this a specific double negative logic implementation in protobuf.spec, or is bcond always used with a double negative type logic. bcond_* is generally misunderstood. *_with does not mean DEFAULT WITH, but on CONDITIONALLY_WITH (as said: conditions can come from CLI, see osc build --with/--without) or could be overruled by prjconf in OBS directly)

I think I got it:

bcond_with rob_bank

means there is no way I'm going to rob a bank unless someone is pointing a gun at my head.

I definitely agree with messy. I'd go as far as saying it is one of the most obtuse syntax'es I have seen. I guess it makes sense to someone.

Greg bconds should be defined in a project config, I've had irritating

On 02/12/2015 22:04, Greg Freemyer wrote: problems with undefined bcond's in spec files but while investigating prjconf's I picked up one time bomb from osc meta prjconf devel:languages:python : #NOTE(toddrme2178): Tumbleweed currently has two versions of npm. Remove this if one versions is removed. %if 0%{?suse_version} > 1315 Prefer: nodejs-npm %endif This one excludes Leap42.1 as well as Sles12. You should have a look at various prjconf files they're very interesting. Regards Dave -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org