MAY OF 2018.
[1.0] TC: too strict requirements on group JE: let's give ourselves some time to come up with better options
[1.0] TC: only yast and rpm display the group value, let's remove it JE: there are other programs that can display or use it in some fashion
[1.0] TC: it does not really make sense to install packages based groups JE: the Group field's purpose is not for installation, but browsing
[1.3] WR: annoyed by wrong or inconsistent groups. JE: I'm on it, fixing it. (To date, around 350 edits could be found from my side alone to that end. In other cases, no edit was needed, or the package has not yet crossed my field of sight.)
[1.4] WR: trying to figure out the single-category group is hard. (JE: agreement; go for tags)
[1.5] MC: recurring packager questions like "What is the Group field for?", "which to choose?" (JE: agreement; go for tags, that seems to work out well for freshcode.club and stackexchange.com)
[1.6] MC: (basically Fedora failed to get a grip on Groups, so the world should remove it) (JE: openSUSE has a grip, so "keep" and/or do tags)
CONCLUSION OF MAY 2018.
Supporters of having some value for "Group":
Jan Engelhardt [1.3] "The grouping made yast something of a "Things to Explore" guide to the packages it had." Scott Bahling @SUSE [1.9] "I'm using the rpm Group tag as a way to index software in Package Hub" Wolfgang Rosenauer @SUSE [1.4] "I use the group index to find software I might be interested in." Adam Majer @SUSE [1.7] "Debian has been using package tags[1] for a number of years in addition to groups." Stefan Behlert @SUSE [1.8] "I personally like the groups. They give you a good hint what a package is for."
Opponents of "Group":
Tomas Chvatal. Apart from the initial message, has not made any reply in that thread to the counter arguments (maybe they were too convincing).
Matěj Cepl Michal Kubecek
The supporters have made their case and commitment to work it. Technically, being a meritocracy, this decided that the Group tag is to stay for the time being, and be enhanced as we go.
JUNE OF 2019.
[2.0] IG: Fedora guy here, I missed the previous discussion on groups, so I am proposing the removal again. JE: Link to the previous discussion.
[2.1] NG: "I'm actually not a fan of the fact Fedora doesn't use the Group tag. ... I'd rather re-introduce a better formulated Group tag"
[2.2] TC: "We are already in process of abandoning it." -> in violation of the May resolution
[2.3] TK: single-value group is useless currently -> the idea of tags is just floating
[2.3] TK: "many Group entries are wrong, useless or something similar" JE: "Most Group entries are actually right", I'm doing the dang reviews where all the spec files pass my eagle eyes.
CONCLUSION OF JUNE 2019.
(New) supporters of having some value for "Group":
Neil Gompa
(New) opponents:
Maurizio Galli (MauG)
AUGUST 2019.
[3.0] TC: "As there was no major pushback", ignores the May result, ignores the June discussion even after being pointed to previous threads.
[3.1] TC: "Your lonely complain is not a major pushback..." JE: This overview is proof of the contrary.
[3.2] SK: "should eliminate *the need* to have a group line." JE: agreement
[3.3] HPJ: "OTOH, I cannot see a good reason to *actively* *eliminate* the Group line"
[3.4] BV: Concern that removing Group is extra work.
CONCLUSION OF AUGUST 2019.
* new .spec files can come without a group line; groups/tags can be added later by those who care * keep Group lines
* A tag browser software is on display to showcase that even the old groups _work reasonably well_ as tags for the purpose of software browsing and discovery. * rpmlint was amended in late September not to warn on wrong group lines anymore * Group: can thus be freeform, allowing for a tag system (whitespace-separated words)
(New) supporters of having some value for "Group":
Hans-Peter Jansen
OCTOBER 2019.
[] Opponents: maintainers are gods over their own packages [4.0] JE: I'm trying to run a distro-wide endeavor here, there should be limits as to what maintainers can and cannot oppose.
[4.2] TK: repeats his prior statement that groups are useless JE: repeats his prior statement that they are in good shape
[4.3] TK: wiki has not corresponded to what the tooling does [4.4] JE: disproves TK and explains the circumstances
[4.5] HPJ gets annoyed by Opponents' removal of Group lines in his package.
OVERALL.
Opponents start killing off Group tag even though that goes directly against the goal of the Group/Tags subproject and its Supporters. Bad.
Opponents claim "it was decided", but this decision was at best unilateral and there is anything _but_ consensus about the removal. In doing so, they also overstep other maintainers [SR 738421]. Very bad.
The wiki has a strange position in all this. Many regard it as an authoritative manual, but only where it is convenient and matches practice.
Right now it says "Group: only package groups listed in the package group guidelines should be used." [5.0] and "New groups can be created by just starting to make use of them in .spec files." [5.1], so I will hold it to that.
MAIL REFERENCES (webview).
[1.0] https://lists.opensuse.org/opensuse-factory/2018-05/msg00460.html [1.3] https://lists.opensuse.org/opensuse-factory/2018-05/msg00507.html [1.4] https://lists.opensuse.org/opensuse-factory/2018-05/msg00511.html [1.5] https://lists.opensuse.org/opensuse-factory/2018-05/msg00517.html [1.6] https://lists.opensuse.org/opensuse-factory/2018-05/msg00517.html [1.7] https://lists.opensuse.org/opensuse-factory/2018-06/msg00004.html [1.8] https://lists.opensuse.org/opensuse-factory/2018-06/msg00131.html [1.9] https://lists.opensuse.org/opensuse-factory/2018-05/msg00503.html
[2.0] https://lists.opensuse.org/opensuse-factory/2019-06/msg00054.html [2.1] https://lists.opensuse.org/opensuse-factory/2019-06/msg00056.html [2.2] https://lists.opensuse.org/opensuse-factory/2019-06/msg00058.html [2.3] https://lists.opensuse.org/opensuse-factory/2019-06/msg00059.html
[3.0] https://lists.opensuse.org/opensuse-factory/2019-08/msg00253.html [3.1] https://lists.opensuse.org/opensuse-factory/2019-08/msg00257.html [3.2] https://lists.opensuse.org/opensuse-factory/2019-08/msg00262.html [3.3] https://lists.opensuse.org/opensuse-factory/2019-08/msg00268.html [3.4] https://lists.opensuse.org/opensuse-factory/2019-09/msg00034.html
[4.0] https://lists.opensuse.org/opensuse-factory/2019-10/msg00039.html [4.2] https://lists.opensuse.org/opensuse-factory/2019-10/msg00046.html [4.3] https://lists.opensuse.org/opensuse-factory/2019-10/msg00048.html [4.4] https://lists.opensuse.org/opensuse-factory/2019-10/msg00051.html
[5.0] https://en.opensuse.org/openSUSE:Specfile_guidelines [5.1] https://en.opensuse.org/openSUSE:Package_group_guidelines
On 2019-10-16 21:56, Jan Engelhardt wrote:
OVERALL.
great summary, thanks.
Opponents start killing off Group tag even though that goes directly against the goal of the Group/Tags subproject and its Supporters. Bad.
Opponents claim "it was decided", but this decision was at best unilateral and there is anything _but_ consensus about the removal. In doing so, they also overstep other maintainers [SR 738421]. Very bad.
Although I'm far away from the center of decisions in the openSUSE project, I also have the gut feeling that a) this topic has not been discussed until the end, and b) no agreed decision has ever been made (or published).
So maybe some of us all have already started with the seemingly easy and tempting task to remove the Group tags - I for myself almost fell in that same mood/trap (but refrained from sending a SR because I wanted to wait for the "official decision", and then removed my branches again).
I personally like Groups. For sure, re-assigning some packages to other Groups may be necessary now and also in future - still I see it's the best categorization we currently have.
Have a nice day, Berny
On Wed, 2019-10-16 at 21:56 +0200, Jan Engelhardt wrote:
<snip childish nonsense>
Jan, I went through the installed packages on my system here and looked casually at the list of packages and their assigned groups.
It led me to the following questions:
what is discord doing in "Amusements/Games/Other"? why is xscreensaver in "Amusements/Toys"? Why is GNOME Builder not in "Development/Tools/IDE" but it's plugins are? Why is Archiving/Backup considered a subcategory of Productivity? Why is does Clustering have to do with Productivity? Why are gstreamer codecs in Productivity/Multimedia/Other when half the codecs it uses are in Productivity/Multimedia/Video/Editors and Converters? Why is guvcview in Productivity/Multimedia/Video/Players when cheese is in Productivity/Multimedia/Other? What is Networking doing under Producitivity? What is IRC doing under Networking? Why is ghostscript in Producitivity/Office/Other when the ghostscript fonts are all under Productivity/Publishing/PS? Why is the ghostscript fonts not under System/X11/Fonts? Why the hell is a gnome-calculator considered Productivity/Scientific/Math and gedit is Productivity/Text/Editors but most of the other GNOME apps are System/GUI/GNOME? Why is apparmor-abstractions Productivity/Security when apparmor-parser is Productivity/Networking/Security? WHAT DOES APPARMOR HAVE TO DO WITH PRODUCTIVITY? Why is sysfsutils in System/Libraries? Why is YaST not System/Management? Why in Podman in System/Management? Why do we have System/Sound Daemons when the only thing in it is PulseAudio and all the other Sound Daemons are in System/Libraries? Wtf is xdmbgrd doing in System/X11/Displaymanagers? WTH is tigervnc doing in System/X11/Servers/XF86_4? WTH is System/X11/Servers/XF86_4? Why is gnome-logs in System/X11/Utilities not System/GUI/GNOME? Why is hicolor-icon-theme in System/X11/Utilities? Why is xorg-x11 in System/X11/Utilities not System/X11/Servers? WTH is numlockx doing in System/YaST?
I imagine if I went through with a fine toothcomb I'd find more examples, plus of course this is a sample size of approximately ~10% of the distributions packages.
More than ever I am now convinced that the RPM Groups we have in the distribution right deserve to be thrown away with prejudice, and I'm not interested in considering an alternative until that's been done so we can start from a nice clean slate.
Regards,
On Thursday 2019-10-17 11:56, Richard Brown wrote:
On Wed, 2019-10-16 at 21:56 +0200, Jan Engelhardt wrote:
<snip childish nonsense>
Jan, I went through the installed packages on my system here and looked casually at the list of packages and their assigned groups.
It led me to the following questions:
I have answered some of these Qs previously somewhere, but because that is loosely scattered, I will do so again here for the viewers' convenience.
Packages can and do get reviewed and checked into Factory quickly, sometimes without me getting a chance to see it in time (this is not a bad thing, it just happens). As mentioned in the past too, if and when I am aware of it, something will be done about it.
what is discord doing in "Amusements/Games/Other"?
I can concur Games feels odd, but, it is my hypothesis the packager thought of Discord as a program similar to TeamSpeak, an application that is used as a sidechannel communication while gaming (gamers seem to shun in-game voice transmission implementations, if they even exist). Basically, this package suffered from the single-valuedness of old groups.
Thank for your making me aware of this package - I will make a proposal to its submitter under the new tag scheme.
(Discord also has that special place in :NonFree...)
why is xscreensaver in "Amusements/Toys"?
Hypothesis: Amusements/ is the antithesis to Productivity/. There is not much you can do during a screensaving moment ;-)
Would you rather expect it in "graphics"?
Why is GNOME Builder not in "Development/Tools/IDE" but it's plugins are?
This is a result of the single-valuedness of groups and because, in that old limited framework, the maintainer decided to highlight the fact that it is a "gnome" component over "ide". I shall make a SR to propose both "gnome" and "ide".
Why is Archiving/Backup considered a subcategory of Productivity? Why is does Clustering have to do with Productivity? What is Networking doing under Producitivity?
Would you rather want to classify Archiving as a non-productive use (i.e. amusements) -- note this is a rhetoric question, I don't expect any answer.
Amusements and Productivity, in my opinion, are purely separators in the classisc cheme. It is useless as a tag and does not appear in the new tag list. All Amusements/X/Y and Productivity/X/Y get reduced to X, Y (or better) when tags are made out of it.
Why are gstreamer codecs in Productivity/Multimedia/Other when half the codecs it uses are in Productivity/Multimedia/Video/Editors and Converters?
It shall be fixed..
Why is guvcview in Productivity/Multimedia/Video/Players when cheese is in Productivity/Multimedia/Other?
Though cheese plays video material, I do not think anyone would consider it a video player (as in, VLC, mplayer), since it is a webcam program.
What is IRC doing under Networking?
Rather than a question about a package's choice of some group, now this is one about the classic groups themselves.
Maybe IRC was seen as a protocol the same way SMTP is. I would suggest not to try to understand the old hierarchy, just fixing it. Hold my beer..
I sure have replies to your other individual question, but I will cut the mail short here so that it gets out to the public faster. I will take your list into consideration and, now that I am aware of more unfitting values, make submissions and get it fixed, like I also said at a past date.
Hi Jan
On 10/17/19 6:26 AM, Jan Engelhardt wrote:
MAY OF 2018.
[1.0] TC: too strict requirements on group JE: let's give ourselves some time to come up with better options
[1.0] TC: only yast and rpm display the group value, let's remove it JE: there are other programs that can display or use it in some fashion
[1.0] TC: it does not really make sense to install packages based groups JE: the Group field's purpose is not for installation, but browsing
I suspect you missed the post that would fit about here [1.1] in the timeline where you agreed that groups should be removed and hence others probably thinking they had a consensus and starting to do the work in yast etc which was completed some 12 months back
1.1: https://lists.opensuse.org/opensuse-factory/2018-05/msg00465.html
On Friday 2019-10-18 08:07, Simon Lees wrote:
[1.0] TC: too strict requirements on group JE: let's give ourselves some time to come up with better options
[1.0] TC: only yast and rpm display the group value, let's remove it JE: there are other programs that can display or use it in some fashion
[1.0] TC: it does not really make sense to install packages based groups JE: the Group field's purpose is not for installation, but browsing
I suspect you missed the post that would fit about here [1.1] in the timeline where you agreed that groups should be removed and hence others probably thinking they had a consensus and starting to do the work in yast etc which was completed some 12 months back
1.1: https://lists.opensuse.org/opensuse-factory/2018-05/msg00465.html
Is it not allowed to change one's mind? As part of that thread, there came a time when I realized, hey, groups not so bad after all if you actually spend time on the matter. https://lists.opensuse.org/opensuse-factory/2018-05/msg00508.html "I would totally want to retain RPM groups [for games]". The natural question then is, why stop at games.
On 10/18/19 6:23 PM, Jan Engelhardt wrote:
On Friday 2019-10-18 08:07, Simon Lees wrote:
[1.0] TC: too strict requirements on group JE: let's give ourselves some time to come up with better options
[1.0] TC: only yast and rpm display the group value, let's remove it JE: there are other programs that can display or use it in some fashion
[1.0] TC: it does not really make sense to install packages based groups JE: the Group field's purpose is not for installation, but browsing
I suspect you missed the post that would fit about here [1.1] in the timeline where you agreed that groups should be removed and hence others probably thinking they had a consensus and starting to do the work in yast etc which was completed some 12 months back
1.1: https://lists.opensuse.org/opensuse-factory/2018-05/msg00465.html
Is it not allowed to change one's mind? As part of that thread, there came a time when I realized, hey, groups not so bad after all if you actually spend time on the matter. https://lists.opensuse.org/opensuse-factory/2018-05/msg00508.html "I would totally want to retain RPM groups [for games]". The natural question then is, why stop at games.
" Maybe this insight helps in finding where to go :)" isn't really a strong indication if others were happy with the removal I can clearly see who they thought they had a general consensus and thefore started the removal work, it was another year before you gave a strong indication that you wanted to keep them and by that time much of the work behind the scenes was done.
On Friday 2019-10-18 10:02, Simon Lees wrote:
Is it not allowed to change one's mind? As part of that thread, there came a time when I realized, hey, groups not so bad after all if you actually spend time on the matter. https://lists.opensuse.org/opensuse-factory/2018-05/msg00508.html "I would totally want to retain RPM groups [for games]". The natural question then is, why stop at games.
" Maybe this insight helps in finding where to go :)" isn't really a strong indication if others were happy with the removal I can clearly see who they thought they had a general consensus and thefore started the removal work,
Fair enough.
it was another year before you gave a strong indication that you wanted to keep them and by that time much of the work behind the scenes was done.
What was done behind the scenes merely involved touching yast and zypper AFAICS (the other part was then in front of the curtain).
It's not like yast is or could be the only catalog browser in the world, so I put that off with a shrug, since the metadata was still there and could be used by any other category browser (it's not like yast is holding a monopoly), so become a new category browser as a proof. As users started to notice yast suddenly lacked a feature, the raison d'etre of the proof kind of came to be. This might give an insight as to why the harder objections came in rather later: because I did not value yast as much as the metadata.
On 10/18/19 6:54 PM, Jan Engelhardt wrote:
On Friday 2019-10-18 10:02, Simon Lees wrote:
Is it not allowed to change one's mind? As part of that thread, there came a time when I realized, hey, groups not so bad after all if you actually spend time on the matter. https://lists.opensuse.org/opensuse-factory/2018-05/msg00508.html "I would totally want to retain RPM groups [for games]". The natural question then is, why stop at games.
" Maybe this insight helps in finding where to go :)" isn't really a strong indication if others were happy with the removal I can clearly see who they thought they had a general consensus and thefore started the removal work,
Fair enough.
it was another year before you gave a strong indication that you wanted to keep them and by that time much of the work behind the scenes was done.
What was done behind the scenes merely involved touching yast and zypper AFAICS (the other part was then in front of the curtain).
Once the "consensus" was found the next step seems to have been that it then went through a internal SUSE change process to be accepted into SLE which is the fate that has been mentioned in some cases. Because of that and rpmlint now being fixed hence why people think it is ok to drop it. rpmlint has been undergoing major changes so I guess that's why it took so long for that part to fall into place otherwise i'm sure they would have started being removed sooner.
Now that all those pieces have fallen into place based off the consensus over a year ago SUES engineers can now remove the Group tag from packages in SLE and other products and most Managers are under the impression that the tags are not needed and can freely be removed.
On Fri, Oct 18, 2019 at 4:57 AM Simon Lees sflees@suse.de wrote:
Once the "consensus" was found the next step seems to have been that it then went through a internal SUSE change process to be accepted into SLE which is the fate that has been mentioned in some cases. Because of that and rpmlint now being fixed hence why people think it is ok to drop it. rpmlint has been undergoing major changes so I guess that's why it took so long for that part to fall into place otherwise i'm sure they would have started being removed sooner.
rpmlint upstream still maintains a Group tag check, openSUSE downstream modified this to match its own policy (different groups set, etc.), but now it's disabled like in Fedora's rpmlint policy.
-- 真実はいつも一つ！/ Always, there's only one truth!
On 16/10/2019 21:56, Jan Engelhardt wrote:
(New) supporters of having some value for "Group":
Hans-Peter Jansen
Count me in as saying the openSUSE specified groups are wanting. I just test built ffmpeg with the following : Productivity/Multimedia/Video/Editors and Convertors:Multimedia/Audio/Editors and Convertors which then appears in the rpm's INFO/GROUP tag.
This proves that the Group: tag is still very useful for categorizing software if filled out in a useful manner with the correct keywords.
Dave Plater
Hi,
On Fri, 18 Oct 2019, Simon Lees wrote:
Once the "consensus" was found the next step seems to have been that it then went through a internal SUSE change process to be accepted into SLE which is the fate that has been mentioned in some cases. Because of that and rpmlint now being fixed hence why people think it is ok to drop it. rpmlint has been undergoing major changes so I guess that's why it took so long for that part to fall into place otherwise i'm sure they would have started being removed sooner.
Now that all those pieces have fallen into place based off the consensus over a year ago SUES engineers can now remove the Group tag from packages in SLE and other products and most Managers are under the impression that the tags are not needed and can freely be removed.
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 still 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 a mass change that's easy to do) if anything it should be fixed if necessary.
And just because a consumer went away (yast, and there were actually sound objections to that removal!) is also no reason to remove any meta data from the packages.
Ciao, Michael.
Am October 21, 2019 12:35:40 PM UTC schrieb Michael Matz matz@suse.de:
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 still 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 a mass change that's easy to do) if anything it should be fixed if necessary.
And just because a consumer went away (yast, and there were actually sound objections to that removal!) is also no reason to remove any meta data from the packages.
+1 from me (personally)
Lars
On 10/21/19 11:33 PM, Lars Vogdt wrote:
Am October 21, 2019 12:35:40 PM UTC schrieb Michael Matz matz@suse.de:
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 still 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 a mass change that's easy to do) if anything it should be fixed if necessary.
According to the fate, dropping them for SLE-15sp2 is fine, SLE-11 is also well and truly end of life.
And just because a consumer went away (yast, and there were actually sound objections to that removal!) is also no reason to remove any meta data from the packages.
+1 from me (personally)
Lars
I somewhat personally agree with this sentiment, however the issue was decided some 15 months back and has taken a while to finally implement no one chose to raise these concerns then and so the people who are passionate about removing them have gone through and done the work required to make it possible to drop them.
There are now suggestions on factory of a "better" way to implement this and we have a copy of all the groups locally that could be used as a starting point without them needing to stay in Factory.
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 still 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 a mass change that's easy to do) if anything it should be fixed if necessary.
According to the fate, dropping them for SLE-15sp2 is fine
It would be naive to think that just because we release SLE15 SP2 (which is still months away), we can forget about earlier service packs.
SLE-11 is also well and truly end of life.
Far from it...
Michal Kubecek
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 still 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 a mass change that's easy to do) if anything it should be fixed if necessary.
According to the fate, dropping them for SLE-15sp2 is fine
It would be naive to think that just because we release SLE15 SP2 (which 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. Where as SLE 15 is a different workflow meaning that direct submissions are more likely.
Am 22.10.19 um 01:04 schrieb Simon Lees:
On 10/21/19 11:33 PM, Lars Vogdt wrote:
Am October 21, 2019 12:35:40 PM UTC schrieb Michael Matz matz@suse.de:
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 still 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 a mass change that's easy to do) if anything it should be fixed if necessary.
According to the fate, dropping them for SLE-15sp2 is fine, SLE-11 is also well and truly end of life.
Oh. I suggest you better ask your sales department. I wonder what we are paying these huge LTSS bills for ;-)
There are now suggestions on factory of a "better" way to implement this and we have a copy of all the groups locally that could be used as a starting point without them needing to stay in Factory.
What does removing a single line of spec file per (sub-)package really gain that it has to be propagaged with such fervor?
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 still 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 a mass change that's easy to do) if anything it should be fixed if necessary.
According to the fate, dropping them for SLE-15sp2 is fine
It would be naive to think that just because we release SLE15 SP2 (which 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.
Wolfgang
On 10/22/19 5:35 PM, Stefan Seyfried wrote:
Am 22.10.19 um 01:04 schrieb Simon Lees:
On 10/21/19 11:33 PM, Lars Vogdt wrote:
Am October 21, 2019 12:35:40 PM UTC schrieb Michael Matz matz@suse.de:
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 still 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 a mass change that's easy to do) if anything it should be fixed if necessary.
According to the fate, dropping them for SLE-15sp2 is fine, SLE-11 is also well and truly end of life.
Oh. I suggest you better ask your sales department. I wonder what we are paying these huge LTSS bills for ;-)
Well some of it probably goes to my salary, given part of my job is providing security fixes for LTSS distro's. As such I know and understand the restrictions on what can go into LTSS updates and am therefore quite confident that dropping groups won't impact or make it any harder to provide maintenance updates, many of the people who want to see groups dropped also work on SLE 11 LTSS.
There are now suggestions on factory of a "better" way to implement this and we have a copy of all the groups locally that could be used as a starting point without them needing to stay in Factory.
What does removing a single line of spec file per (sub-)package really gain that it has to be propagaged with such fervor?
Nothing, the original intention was to slowly drop them over time, many packagers like to use the time between major releases to give there packages a bit of a tidy up removing redundant info as they go these kind of changes to remove groups that we no longer use fit that category and people care enough about the cleanup process to go through the paperwork to be allowed to include such changes in upcoming releases.
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 still 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 a mass change that's easy to do) if anything it should be fixed if necessary.
According to the fate, dropping them for SLE-15sp2 is fine
It would be naive to think that just because we release SLE15 SP2 (which 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).
Richard.
On 10/22/19 6:51 PM, 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 still 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 a mass change that's easy to do) if anything it should be fixed if necessary.
According to the fate, dropping them for SLE-15sp2 is fine
It would be naive to think that just because we release SLE15 SP2 (which 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.
Then as the maintainer of that package no ones forcing you to drop the group you can keep it for as long as you need, but for those of us that are limited to calling osc mbranch and adding some more patches in our maintenance updates there's no reason not to drop them as we clean up our packages.
On Tue, Oct 22, 2019 at 7:09 AM Richard Biener rguenther@suse.de wrote:
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 > still > 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 > a > mass > change that's easy to do) if anything it should be fixed if > necessary.
According to the fate, dropping them for SLE-15sp2 is fine
It would be naive to think that just because we release SLE15 SP2 (which 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).
This can actually be fixed with a custom macros package injected into the buildroot. That's how we avoided these problems with EL5 in Fedora EPEL.
The defattr thing is just part of SLE's broken rpmlint policy. SLE 12 rpm is fine with no %defattr settings.
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).
Fix the broken policies that enforce rules that haven't been needed since RHEL 4 / SLE 10, then.
Am 22.10.19 um 13:12 schrieb Simon Lees:
Then as the maintainer of that package no ones forcing you to drop the group you can keep it for as long as you need, but for those of us that are limited to calling osc mbranch and adding some more patches in our maintenance updates there's no reason not to drop them as we clean up our packages.
It would still be useful for many people in the community if it was possible to build current packages also on older releases.
The epel-rpm-macros in fedora are a really nice and useful example of a community that considers backwards compatibility at least to some extent.
On 10/22/19 9:39 PM, Richard Biener wrote:
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 > still > 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 > a > mass > change that's easy to do) if anything it should be fixed if > necessary.
According to the fate, dropping them for SLE-15sp2 is fine
It would be naive to think that just because we release SLE15 SP2 (which 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).
Well Factory-First is more about ensuring that stuff in SLE-12 / SLE-15 also makes it into SLE-16. Not about having the latest version of everything building and installable in an unsupported fashion.
As a side note personally I don't have the spec cleaner service setup, I got sick of it causing chaos with my maintenance updates, now I just run it when i'm intentionally cleaning up a package.
On 10/22/19 10:01 PM, Stefan Seyfried wrote:
Am 22.10.19 um 13:12 schrieb Simon Lees:
Then as the maintainer of that package no ones forcing you to drop the group you can keep it for as long as you need, but for those of us that are limited to calling osc mbranch and adding some more patches in our maintenance updates there's no reason not to drop them as we clean up our packages.
It would still be useful for many people in the community if it was possible to build current packages also on older releases.
The epel-rpm-macros in fedora are a really nice and useful example of a community that considers backwards compatibility at least to some extent.
This is happening in some places, before I start replacing %make_jobs with %cmake_build in a bunch of spec files, we've made sure that the macro is available for build in older still supported distro's. Unfortunately these generally end up in an update repo, this means they are sometimes only available on SUSE's internal build services and Leap + stuff like packagehub.
Hello,
Am Dienstag, 22. Oktober 2019, 01:04:22 CEST schrieb Simon Lees:
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 still 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 a mass change that's easy to do) if anything it should be fixed if necessary.
According to the fate, dropping them for SLE-15sp2 is fine, SLE-11 is also well and truly end of life.
One part you didn't answer is SLE 12 - what's the plan for group tags there? (Not that I care about SLE personally, but it would be still good to know.)
And just because a consumer went away (yast, and there were actually sound objections to that removal!) is also no reason to remove any meta data from the packages.
+1 from me (personally)
Since I'm already writing this mail, I'll add another +1
There are now suggestions on factory of a "better" way to implement this and we have a copy of all the groups locally that could be used as a starting point without them needing to stay in Factory.
And this list is available where? (Hint: keeping the group in the spec file would make it much easier to find it - no need to search in a big list.)
Regards,
Christian Boltz
On Dienstag, 22. Oktober 2019 13:09:02 CEST Richard Biener wrote:
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 > still > 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 > a > mass > change that's easy to do) if anything it should be fixed if > necessary.
According to the fate, dropping them for SLE-15sp2 is fine
It would be naive to think that just because we release SLE15 SP2 (which 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.
So if you want compatibility with old SLE releases, please go forward and provide the needed information.
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 unreasonable.
Kind regards,
Stefan-- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
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.
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.
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 unreasonable.
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.
Michal Kubecek
On Tue, 22 Oct 2019, Brüns, Stefan wrote:
On Dienstag, 22. Oktober 2019 13:09:02 CEST Richard Biener wrote:
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 >> still >> 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 >> a >> mass >> change that's easy to do) if anything it should be fixed if >> necessary.
According to the fate, dropping them for SLE-15sp2 is fine
It would be naive to think that just because we release SLE15 SP2 (which 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 package.
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 unreasonable.
Note I somewhat fail to see the point in removing defattr or BuildRoot. But well ...
Richard.
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)
Hello,
On Wed, 23 Oct 2019, Stefan Seyfried wrote:
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.
While I do see the value in this, there's one other thing to consider: some of our packages are actually not merely building for old distros for our convenience, but rather with the intention of them actually getting into the old SLE trees themself. For these such hackery would be harmful: you believer everything is fine and dandy because it builds in your own repo for old distros just fine, but then when the time comes to submit it to SLE-12:GA you go "aw crap, need to fix all these errors" ;-)
So, yeah, Richis idea of backporting new macros to old SLE trees has some merit (though of course this might bring its own problems which might not be wanted in those trees). Until then we'll have to reject (or revert) some of the changes, especially if they aren't making the world that much better.
Ciao, Michael.
On 10/22/19 11:08 PM, Christian Boltz wrote:
Hello,
Am Dienstag, 22. Oktober 2019, 01:04:22 CEST schrieb Simon Lees:
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 still 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 a mass change that's easy to do) if anything it should be fixed if necessary.
According to the fate, dropping them for SLE-15sp2 is fine, SLE-11 is also well and truly end of life.
One part you didn't answer is SLE 12 - what's the plan for group tags there? (Not that I care about SLE personally, but it would be still good to know.)
Given the stage that SLE-12 SP5 development is now at I suspect its much less likely that anyone would care about making the changes there.
And just because a consumer went away (yast, and there were actually sound objections to that removal!) is also no reason to remove any meta data from the packages.
+1 from me (personally)
Since I'm already writing this mail, I'll add another +1
There are now suggestions on factory of a "better" way to implement this and we have a copy of all the groups locally that could be used as a starting point without them needing to stay in Factory.
And this list is available where? (Hint: keeping the group in the spec file would make it much easier to find it - no need to search in a big list.)
Its not exactly a List per say, its more an archive of all the spec files in factory as of a week or three before the change, with the right invocation on the command line one could likely form a list in a way that's ideal for importing into whatever new tool is adopted.
If someone wants a copy of this archive I can probably arrange to give it to them.
On 10/22/19 11:59 PM, Brüns, Stefan wrote:
On Dienstag, 22. Oktober 2019 13:09:02 CEST Richard Biener wrote:
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 >> still >> 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 >> a >> mass >> change that's easy to do) if anything it should be fixed if >> necessary.
According to the fate, dropping them for SLE-15sp2 is fine
It would be naive to think that just because we release SLE15 SP2 (which 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.
So if you want compatibility with old SLE releases, please go forward and provide the needed information.
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 unreasonable.
Generally its up to the project maintainer to decide what they think would be useful to enable. But for those of us submitting changes into maintenance for LTSS repos we are pretty much always branching the existing package and maybe adding one or two patches or fixing something minor in the spec file. So having the latest version still building in tumbleweed doesn't make much sense for us.
Taking a couple of examples I maintain for example, the first being dbus, I would expect that very few people would really want to run the latest version of dbus on an older Leap / SLE install so I don't put much effort into keeping it building in older versions if it still works it works if it doesn't I don't really care, if someone feels like sending a fix i'll probably accept it. On the other hand I also maintain the fish shell and people do tend to like to have the latest version of that on everything so i'll tend to make sure that it still builds everywhere.
-
Bernhard Voelker -
Brüns, Stefan -
Christian Boltz -
Dave Plater -
Jan Engelhardt -
Lars Vogdt -
Michael Matz -
Michal Kubecek -
Neal Gompa -
Richard Biener -
Richard Brown -
Simon Lees -
Stefan Seyfried -
Wolfgang Rosenauer