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