[opensuse-packaging] suse_version handling troubles/solutions
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
On Thu, Jun 11, Tomáš Chvátal wrote:
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.
Its easy to find differences between 13.1, SLE12 and 13.2 because the trees are available. Knowing how todays and last months TW snapshot differ is timeconsuming and cumbersome. Not sure if the new post-SLE12-GA approach is supposed to be a moving target like Factory/TW. If its supposed to be a release then it gets a suse_version. Given the roadmaps I have seen suse_version can cope with the roadmap: 1315 = GA 1316 = SP1+ etc. Olaf -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
Hello, On Jun 11 13:46 Olaf Hering wrote (excerpt):
Given the roadmaps I have seen suse_version can cope with the roadmap: 1315 = GA 1316 = SP1+ etc.
Some time ago I was (somewhat imperiously) told that distinguishing between SLE service packs is wrong. If I remember correctly the reason behind is that a package e.g. for SLE11 must be installable in SLE11-GA and in any SLE11 service pack. This is confirmed in https://en.opensuse.org/openSUSE:Build_Service_cross_distribution_howto -------------------------------------------------------- ServicePacks cannot be distinguished. SLES11 SP1 sets exactly the same variables as SLES11. -------------------------------------------------------- Accordingly there will not be 1316 for SLE12-SP1. SLE12-GA and all SLE12 service packs will have 1315. Kind Regards Johannes Meixner -- SUSE LINUX GmbH - GF: Felix Imendoerffer, Jane Smithard, Dilip Upmanyu, Graham Norton - HRB 21284 (AG Nuernberg) -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
Hi, On Thu, Jun 11, Johannes Meixner wrote:
Some time ago I was (somewhat imperiously) told that distinguishing between SLE service packs is wrong.
If I remember correctly the reason behind is that a package e.g. for SLE11 must be installable in SLE11-GA and in any SLE11 service pack.
This is not really correct and far to simplyfied. The problem is that most of this changes are coming between Service-Packs, so that you would need to distinguish between if this change is already installed on the system or not. Besides some other good reasons. Thorsten -- Thorsten Kukuk, Senior Architect SLES & Common Code Base SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany GF: Felix Imendörffer, Jane Smithard, Dilip Upmanyu, Graham Norton, HRB 21284 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
Hello, On Jun 11 14:50 Thorsten Kukuk wrote (excerpt):
The problem is that most of this changes are coming between Service-Packs, so that you would need to distinguish between if this change is already installed on the system or not. Besides some other good reasons.
Are those good reasons confidential? If not, could you provide that good reasons because at least for me it feels better when I know why I do something in contrast to blind obedience. In particluar because what Tomáš Chvátal wrote seems to be a contradicting idea:
Introduce extra macro, ie %opensuse_version YYYYMMDD which would be based on the snapshots and always bumped, so we can seriously finegrain what to
Only a gut feeling: I think such finegrained dependencies lead to spec files where after some time nobody understands what such dependencies actually mean. I even think using product version tests in spec files is fundamentally inappropriate because such tests do not test for the actual requirement. Therefore the plain test is meaningless so that additional comments are required that tell what is going on, e.g.: ------------------------------------------------------------------ # Since openSUSE 13.2 the package foo provides something: %if 0%{?suse_version} >= 1320 BuildRequires: foo %endif . . . # Up to openSUSE 13.1 the package foo does not provide something: %configure \ %if 0%{?suse_version} <= 1310 --without-something \ %endif ------------------------------------------------------------------ Intentionally I made here the mistake to leave out 1315. I would prefer if I could test for the actual requirement like ------------------------------------------------------------------ %if %build_system_package_version foo >= 1.2.3 BuildRequires: foo %endif . . . %configure \ %if %build_system_package_version foo >= 1.2.3 --with-something \ %else --without-something \ %endif ------------------------------------------------------------------ or even better like ------------------------------------------------------------------ %if %build_system_package_provides foo something BuildRequires: foo %endif . . . %configure \ %if %build_system_package_provides foo something --with-something \ %else --without-something \ %endif ------------------------------------------------------------------ Kind Regards Johannes Meixner -- SUSE LINUX GmbH - GF: Felix Imendoerffer, Jane Smithard, Dilip Upmanyu, Graham Norton - HRB 21284 (AG Nuernberg)
On Thursday 2015-06-11 15:52, Johannes Meixner wrote:
I would prefer if I could test for the actual requirement like ------------------------------------------------------------------ %if %build_system_package_version foo >= 1.2.3 BuildRequires: foo %endif
But exactly that was already identified to be a problem of its own. In one repository, you have foo>= 1.2.3, and in another you don't, making the whole thing not as reproducible as one would want to. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
Hello, On Jun 11 15:55 Jan Engelhardt wrote (excerpt):
On Thursday 2015-06-11 15:52, Johannes Meixner wrote:
I would prefer if I could test for the actual requirement like ------------------------------------------------------------------ %if %build_system_package_version foo >= 1.2.3 BuildRequires: foo %endif
But exactly that was already identified to be a problem of its own. In one repository, you have foo>= 1.2.3, and in another you don't, making the whole thing not as reproducible as one would want to.
Yes I know. If I want to ensure it is compiled "--with-something" for openSUSE >= 13.2 I would specify that as my actual condition if the plain version value is actually the real requirement (but see what I wrote at the end): ------------------------------------------------------------------------- # Since openSUSE 13.2 compile it "--with-something": %if 0%{?suse_version} >= 1320 BuildRequires: something %endif . . . # Since openSUSE 13.2 compile it "--with-something": %configure \ %if 0%{?suse_version} >= 1320 --with-something \ %endif ------------------------------------------------------------------------- I don't remember if "BuildRequires: any_RPM_capability" works - i.e. when package foo provides something that then "BuildRequires: something" installs package foo. But again the test for the product version does not tell why for openSUSE >= 13.2 it must be compiled "--with-something". Assume for openSUSE >= 13.2 it must be compiled "--with-something" because for openSUSE >= 13.2 there the dependant package bar >= 1.2.3 which requires it to be compiled "--with-something" then I would like to specify the actual requirement like: ------------------------------------------------------------------------- %if %package_version bar >= 1.2.3 BuildRequires: something Essentialfor: bar >= 1.2.3 %else Conflicts: bar >= 1.2.3 %endif . . . %configure \ %if %package_version bar >= 1.2.3 --with-something \ %endif ------------------------------------------------------------------------- Again the test for the package bar version does not tell why that version makes a difference so that even this version test should be ideally replaced with an actual requirement like: ------------------------------------------------------------------------- %if %package_requires bar something_related BuildRequires: something Essentialfor: bar requires something_related %else Conflicts: bar requires something_related %endif . . . %configure \ %if %package_requires bar something_related --with-something \ %endif ------------------------------------------------------------------------- An obvious precondition is that package bar >= 1.2.3 has a RPM requirement for something_related. It depends what something_related is. It could be even the same as "something". E.g. assume "something_related" is "/usr/bin/fancy_tool" which is provided by the package foo. Then package bar >= 1.2.3 could have ------------------------------------------------------------------------- Requires: /usr/bin/fancy_tool ------------------------------------------------------------------------- and the tests could look like ------------------------------------------------------------------------- %if %package_requires bar /usr/bin/fancy_tool BuildRequires: /usr/bin/fancy_tool Essentialfor: bar requires /usr/bin/fancy_tool %define with_or_without_fancy_tool_support --with-fancy-tool-support %else Conflicts: bar requires /usr/bin/fancy_tool %define with_or_without_fancy_tool_support --without-fancy-tool-support %endif . . . %configure \ %with_or_without_fancy_tool_support \ ------------------------------------------------------------------------- In the end what I like to tell is that tests for versions result meaningless code in the spec files. Therefore I think it would be good if tests for versions could be in the future replaced by tests for actual requirements except the plain version value is the actual requirement. For example assume in a future product openSUSE 42.0 support for /usr/bin/fancy_tool in package bar is wanted. Then a patterns RPM spec file for openSUSE 42.0 could contain something like ------------------------------------------------------------------------- %if 0%{?suse_version} >= 4200 Requires: bar requires /usr/bin/fancy_tool %endif ------------------------------------------------------------------------- instead of a meaningless ------------------------------------------------------------------------- %if 0%{?suse_version} >= 4200 Requires: bar >= 1.2.3 %endif ------------------------------------------------------------------------- Kind Regards Johannes Meixner -- SUSE LINUX GmbH - GF: Felix Imendoerffer, Jane Smithard, Dilip Upmanyu, Graham Norton - HRB 21284 (AG Nuernberg) -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
Johannes Meixner <jsmeix@suse.de> writes:
I don't remember if "BuildRequires: any_RPM_capability" works - i.e. when package foo provides something that then "BuildRequires: something" installs package foo.
It does. Andreas. -- Andreas Schwab, SUSE Labs, schwab@suse.de GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7 "And now for something completely different." -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On 11.06.2015 17:14, Andreas Schwab wrote:
Johannes Meixner <jsmeix@suse.de> writes:
I don't remember if "BuildRequires: any_RPM_capability" works - i.e. when package foo provides something that then "BuildRequires: something" installs package foo.
It does.
We use it a lot for pkgconfig(QtCore) and perl(Test::More) Greetings, Stephan -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
Johannes Meixner wrote:
On Jun 11 15:55 Jan Engelhardt wrote (excerpt):
On Thursday 2015-06-11 15:52, Johannes Meixner wrote:
I would prefer if I could test for the actual requirement like ------------------------------------------------------------------ %if %build_system_package_version foo >= 1.2.3 BuildRequires: foo %endif
But exactly that was already identified to be a problem of its own. In one repository, you have foo>= 1.2.3, and in another you don't, making the whole thing not as reproducible as one would want to.
Yes I know.
If I want to ensure it is compiled "--with-something" for openSUSE >= 13.2 I would specify that as my actual condition if the plain version value is actually the real requirement (but see what I wrote at the end): ------------------------------------------------------------------------- # Since openSUSE 13.2 compile it "--with-something": %if 0%{?suse_version} >= 1320 BuildRequires: something %endif . . . # Since openSUSE 13.2 compile it "--with-something": %configure \ %if 0%{?suse_version} >= 1320 --with-something \ %endif
%if 0%{?suse_version} >= 1320 %bcond_without something %else %bcond_with something %endif ... %configure \ %{?with_something:--with-something} cu Ludwig -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.de/ SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Dilip Upmanyu, Graham Norton, HRB 21284 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On Thu, Jun 11, Johannes Meixner wrote:
Hello,
On Jun 11 13:46 Olaf Hering wrote (excerpt):
Given the roadmaps I have seen suse_version can cope with the roadmap: 1315 = GA 1316 = SP1+ etc.
Some time ago I was (somewhat imperiously) told that distinguishing between SLE service packs is wrong.
It likely is. The change between SUSE:SLE-12:GA and openSUSE:42 will likely be intrusive enough to warrant a different suse_version. Olaf -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On 11.06.2015 15:25, Olaf Hering wrote:
On Thu, Jun 11, Johannes Meixner wrote:
Hello,
On Jun 11 13:46 Olaf Hering wrote (excerpt):
Given the roadmaps I have seen suse_version can cope with the roadmap: 1315 = GA 1316 = SP1+ etc.
Some time ago I was (somewhat imperiously) told that distinguishing between SLE service packs is wrong.
It likely is. The change between SUSE:SLE-12:GA and openSUSE:42 will likely be intrusive enough to warrant a different suse_version.
It will break way too much because 1315 is compared with == ;( Greetings, Stephan -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On Thu, Jun 11, Stephan Kulow wrote:
On 11.06.2015 15:25, Olaf Hering wrote:
On Thu, Jun 11, Johannes Meixner wrote:
Hello,
On Jun 11 13:46 Olaf Hering wrote (excerpt):
Given the roadmaps I have seen suse_version can cope with the roadmap: 1315 = GA 1316 = SP1+ etc.
Some time ago I was (somewhat imperiously) told that distinguishing between SLE service packs is wrong.
It likely is. The change between SUSE:SLE-12:GA and openSUSE:42 will likely be intrusive enough to warrant a different suse_version.
It will break way too much because 1315 is compared with == ;(
Yes. Leaving 1315 as "SLE12 code stream" and introducing a new variable to distinguish between releases in that code stream sounds like the best approach. Olaf -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
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.
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. Thorsten -- Thorsten Kukuk, Senior Architect SLES & Common Code Base SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany GF: Felix Imendörffer, Jane Smithard, Dilip Upmanyu, Graham Norton, HRB 21284 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
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
On Thu, Jun 11, 2015 at 01:23:06PM +0200, Tomáš Chvátal wrote:
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.
I like this idea. I don't like the name - to use a keyword containing "Requires" for something that is not required would be confusing. Perhaps BuildRecommend? We might want to go a step further. Many of my suse_version tests are to handle packages named differently in different versions. What I would appreciate would be syntax like e.g. BuildRequires: (name1 name2 name3) which would take first name available. (The new keyword should also support this syntax.) Michal Kubeček -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
participants (9)
-
Andreas Schwab -
Jan Engelhardt -
Johannes Meixner -
Ludwig Nussel -
Michal Kubecek -
Olaf Hering -
Stephan Kulow -
Thorsten Kukuk -
Tomáš Chvátal