@pluskalm could you please check if it will build against SLE12 SP5 (I added the build target to the projcet) and retest if you can build against it. Before your change, asusfan was built successfully against SLE12 SP4.
And this default is good when one wants to build software which is installable on GA product - which is valid usecase for some. Defaults cant adress all the needs of all users.
Any change that is introducing changes which are not backwards compactible is "breaking" - that being said lack of this macro has been aressed by maintenance updated and is resolved for SLE-12-SP5
Also, why the heck should community care about something building for SLE-12? If there is such a burden on project is it communicated somehow/somewhere?
If you want to use %make_build and it is not defined in all non-obsolete projects please use conditional expansion and supply a reasonable fallback for cases when the macro is not defined.
Maybe community does not need to care about buildability of packages against SLE12 but you as SUSE employee should. PackageHub is a thing even for releases without a Leap counterpart.
To get some facts straight:
1) even if this sr breaks build against SLE-12-GA, rpm for said build target will be preserved as long as build target is present
2) regarding backports/PackageHub project, asusfan is present in PackageHub for SLE-15 and was never submited requested for PackageHub for SLE-12. PackageHub-12 as I would call it is currently recieving mostly bugfixes and security fixes, there is very little of new submissions. Should such need arise, package can be submitted either from factory of from Leap - and again Leap package version is buildable against GA. That being said even Factory version would still build for PackageHub-12 as this is treated as regular maintanance project - and everything is build against :Update repository - we actually had several maintenance updates for SLE to enable building of stuff for PackageHub
3) Should devel's project policy, agreed by its maintainers be that packages have to maintain backwards compatibility - it should be, as is common stated in devel project description - it is hovewer not
Overall I am under impression that you are just trying to find a justification to bash this sr - I dare not speculate about your motives.
@pluskalm could you please check if it will build against SLE12 SP5 (I added the build target to the projcet) and retest if you can build against it. Before your change, asusfan was built successfully against SLE12 SP4.
make_build macro is just not defined in that release, I suggest to let it be. we need cleanly packages instead of highly backward compatible ones.
This is a good point. If you want, you can merge it. Otherwise it looks good to me.
Afaik it would build if Update instead of GM was used as build target - but thats something that has to be adressed at project level config
And project admins get this setup from OSC defaults which should be addressed in builservice config.
And this default is good when one wants to build software which is installable on GA product - which is valid usecase for some. Defaults cant adress all the needs of all users.
If nothing other than this 'cleanup' prevents building the package on SLE12 this is a braking change.
Any change that is introducing changes which are not backwards compactible is "breaking" - that being said lack of this macro has been aressed by maintenance updated and is resolved for SLE-12-SP5
Also, why the heck should community care about something building for SLE-12? If there is such a burden on project is it communicated somehow/somewhere?
Anyways I have filled in delete request for this package for Factory, it would be dropped anyways
Same applies to spec-cleaner. It only provides defaults which may not be suitable for every situation.
Usage of %make_build is considered desirable. It is also ok with original maintainer of package as stated above.
If you want to use %make_build and it is not defined in all non-obsolete projects please use conditional expansion and supply a reasonable fallback for cases when the macro is not defined.
Maybe community does not need to care about buildability of packages against SLE12 but you as SUSE employee should. PackageHub is a thing even for releases without a Leap counterpart.
Please dont tell me what should I do and what should I not do - I think we will continue this discussion in less public channel
Indeed, that's not my job. Sorry about that.
To get some facts straight: 1) even if this sr breaks build against SLE-12-GA, rpm for said build target will be preserved as long as build target is present
2) regarding backports/PackageHub project, asusfan is present in PackageHub for SLE-15 and was never submited requested for PackageHub for SLE-12. PackageHub-12 as I would call it is currently recieving mostly bugfixes and security fixes, there is very little of new submissions. Should such need arise, package can be submitted either from factory of from Leap - and again Leap package version is buildable against GA. That being said even Factory version would still build for PackageHub-12 as this is treated as regular maintanance project - and everything is build against :Update repository - we actually had several maintenance updates for SLE to enable building of stuff for PackageHub
3) Should devel's project policy, agreed by its maintainers be that packages have to maintain backwards compatibility - it should be, as is common stated in devel project description - it is hovewer not
Overall I am under impression that you are just trying to find a justification to bash this sr - I dare not speculate about your motives.
Fine, you have proven it is fine to break this particular package on SLE12. It would have been much easier to just not break it.
No, it would have been easier to just not have this conversation.
@a_faerber, @duwe, @elvigia, @hreinecke, @lrupp, @michals, @seife, @seilerphilipp, @trenn, @tsaupe: review reminder