Hi Michal,
Am 23.10.19 um 07:57 schrieb Michal Kubecek:
On Tuesday, 22 October 2019 15:29 Brüns, Stefan wrote:
I have seen many complaints from a few people who request to keep SLE11/12 compatibility (but which SLE12? SP1-4, i.e. LTSS, or SP4 only?), but I am totally missing anything *constructive*. No guiding documentation, no review comments, no SRs fixing builds.
So if you want compatibility with old SLE releases, please go forward and provide the needed information.
I chose to believe it's just lack of information from your side and you are not mocking us deliberately. The reality is that I tried to fix build issues with older SLE releases or revert "cleanup" changes which broke the build. Most of the time, the response was like "No, we won't clutter our precious specfile just for compatibility with products which are long dead." (Where "long dead" often meant products still in regular support phase.) Eventually, I gave up and keep forks of packages I care about most in my home project. I'm pretty sure I'm not the only one with similar experience and resolution.
What I really like is the fedora "epel-rpm-macros"-style way of just adding backwards compatibility via clever (even is sometimes "ugly" looking) rpm macro / config tricks.
Maybe we can come up with similar "add on config"-RPMS that can be additionally added to older buildroots in prjconf to make life easier.
One might ask if multiple people keeping forks of the same package in their home projects (and OBS having to rebuild all of them) is an acceptable price for having specfiles perfectly following the latest guidelines.
I at least provide my own build power by running private OBS instances where those packages are built ;-) but I could certainly use some of that paid work time I'm investing into keeping the packages building (and rebasing the hacks after every update...) to work on openSUSE packages instead.
Personally, I find having newer versions of packages like libcap, tcpdump and other diagnostic and debugging tools available for older SLE products (including those in LTSS maintenance phase) highly beneficial for my work.
Exactly. And if we can make it easy to build new stuff unchanged even on old distributions, then that would save many persons many hours.
BTW: I now found, that a carefully crafted /etc/rpmlint/disable-crazy.config, just "addFilter()"-ing away the crazy stuff in an additional package already can solve many of the rpmlint annoyances, so i'll try next if I'm able to compose a "sles12-backwardcompat-rpm-macros" package that will handle "%license -> %doc" and other things.
(As I'm running my own OBS instance, I can always patch the spec file during build VM setup, but that's rather ugly, even though I have done this before, see https://lists.opensuse.org/opensuse-buildservice/2015-11/msg00046.html)