Mailinglist Archive: opensuse-packaging (118 mails)

< Previous Next >
Re: [opensuse-packaging] suse_version handling troubles/solutions
  • From: Tomáš Chvátal <tchvatal@xxxxxxx>
  • Date: Thu, 11 Jun 2015 15:04:25 +0200
  • Message-id: <32593527.CUSO53chRx@bugaboo>
Dne Čt 11. června 2015 14:52:48, Thorsten Kukuk napsal(a):
Hi,

On Thu, Jun 11, Tomáš Chvátal wrote:
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...

Don't really understand what you want to reach here.

Problem is that you want magicall switches for when some feature gets
backported to SLE while previously was only in some tumbleweed release.

But with 2 variables as Coolo said on -factory it should be doable, just PITA
to remember there was 1320 which we should never reach (plenty of stuff now has
check suse_version > 1320 which gets kinda borked now).


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.

This would become a nightmare, since the package feature set would depend
on which other RPMs are by design or luck in a repo or not.
Means in one home project it works, in another it does not work. Or
it works in the devel project where the package 'bla' is missing, and
stops working in Tumbleweed, where the package 'bla' is available.

Not really, it would work basically like useflags in Gentoo... while it would
detect package and then provide you define based on the seach, rather than
having switch and then search for package.

It also expects packagers to have proper configure (or other build system)
arguments to allow on/off switches based on features to be found.

Anyway even now the way our specs are written we lose silently features
because configure detection failed and nobody verified buildlogs...

But TBH the first solution with one extra macro is way easier to implement, so
I bet we will go that way.

Tom
< Previous Next >