Mailinglist Archive: opensuse-packaging (118 mails)

< Previous Next >
[opensuse-packaging] suse_version handling troubles/solutions
  • From: Tomáš Chvátal <tchvatal@xxxxxxx>
  • Date: Thu, 11 Jun 2015 13:23:06 +0200
  • Message-id: <1655989.xupb4gtK8K@bugaboo>
Hello,

As discussed a bit on the 42 thread and I don't wanna get it lost in some
crazy deep thread on Factory.

%suse_version is not really well set-up for our mix of sle/opensuse so we need
to devise something to solve the trouble.

There are multiple solutions:

1)
Introduce extra macro, ie %opensuse_version YYYYMMDD which would be based on
the snapshots and always bumped, so we can seriously finegrain what to enable.

This has problem if we backport back the features back to SLE so suddenly they
are supposed to be covered just by %suse_version thing.

Or we would need to mesh in that anything %suse_version 12 %opensuse_version
ANYTHING is older than %suse_version 12.1...

2)
Redo how we think about optional features and why we use the suse_version.

Instead of
%if suse_version > 1140
BuildRequires: bla
%endif
We could devise in rpm like TryBuildRequires which would pull in packages if
they are around and otherwise provide some packagename = 0 for further
depending conditions.

For defines we could instead of version requirement check for the define and if
not found, define it with expected value/behaviour (like in python packages),
and so on.

As coolo already pointed out on factory ml it is not all uses for the
suse_version. But most common usage in spec files is the above and it would
reduce the "prone to error" path quite bit I suppose.

Would it be worth all the work?

Tom
< Previous Next >