On Tue, 22 Oct 2019, Brüns, Stefan wrote:
On Dienstag, 22. Oktober 2019 13:09:02 CEST Richard
On Tue, 22 Oct 2019, Wolfgang Rosenauer wrote:
Am 22.10.19 um 08:52 schrieb Simon Lees:
On 10/22/19 3:20 PM, Michal Kubecek wrote:
> On Tuesday, 22 October 2019 1:04 Simon Lees wrote:
>> On 10/21/19 11:33 PM, Lars Vogdt wrote:
>>> Am October 21, 2019 12:35:40 PM UTC schrieb Michael Matz
>>>> I've certainly declined all SRs removing Groups from my packages,
>>>> they are
>>>> supposed to stay the same for SLE11/12/15 and there groups are
>>>> shown. And of course I'm of the same opinion like Jan, instead of
>>>> removing metadata and replacing them by nothing (which of course is
>>>> change that's easy to do) if anything it should be fixed if
>> According to the fate, dropping them for SLE-15sp2 is fine
> It would be naive to think that just because we release SLE15 SP2
> is still months away), we can forget about earlier service packs.
Yes but the work flow is different, for many packages this removal could
happen now at the maintainers discretion because the spec file as it is
in factory will never be copied directly into a maintenance update.
This is not true. Quite some of the packages I maintain are kept in a
way to be reused everywhere and this also happens for maintenance updates.
Yeah, me too. Those cleanups are really annoying in that light since
they make packages not build on SLE anymore (for example removing
BuildRoot breaks build on SLE11, removing defattr breaks build on SLE12).
If it's called Factory-first then we should live to that promise and
make Factory packages accepted (by checkers, linters and syntax-wise)
by products we still need to maintain (for example by updating those
checkers, linters and rpm).
One obvious problem is the total lack of any definitive guide which versions
should be targeted.
There are dates available at https://www.suse.com/lifecycle/
, but which apply?
General Support or LTSS?
Some devel projects seem to stick to the General Support timeframe (using the
repositories enabled in the projects as indicator), some only target Factory,
some even have SLE12 SP0 (which is out of LTSS).
Even for projects where SLE11 SP4 is still enabled, many packages are
unresolvable or fail to build. Obviously, keeping SLE11 support in these
packages is pointless.
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.
I guess it's really depending on the actual package. For example the
core toolchain is updated regularly for SLE12 and SLE15, receiving
new binutils, gdb and gcc copied from Factory. Removal of defattr
breaks build on SLE12 which is far from out of general maintainance
(there's even a new SP in development). For SLE11 the situation may
be a bit different, but as said, it probably depends on the actual
So if you want compatibility with old SLE releases,
please go forward and
provide the needed information.
I would really really prefer if our internal SLE infrastructure would
simply allow packages following latest Factory guildelines even if that
means updating/patching rpm, brp-* scripts or linters.
But I have been talking to walls here.
Personally, I see no reason to put extra work into
releases which are out of
General Support. LTSS support should be security fixes, but demanding new
packages for e.g. SLE11 SP4, creating some untested Wolpertinger is IMHO
Note I somewhat fail to see the point in removing defattr or BuildRoot.
But well ...
Richard Biener <rguenther(a)suse.de>
SUSE Software Solutions Germany GmbH, Maxfeldstrasse 5, 90409 Nuernberg,
Germany; GF: Felix Imendörffer; HRB 36809 (AG Nuernberg)