On Sat, 2018-09-22 at 13:07 +0200, Kevin Kofler wrote: > Adam Williamson wrote: > > While doing this extremely tedious task, it occurred to me to think: > > what the hell is the *point* of these 'optional' entries any more, > > anyway? > > They are required for Dnfdragora to list the available packages in a > categorized manner. Dropping them without replacement is clearly the wrong > approach, it will badly break Dnfdragora. (Experience with Apper has shown > that users see browsing groups as an absolutely required feature of a > package manager. The uncategorized "all packages" list or searches by name > or description are not suitable replacements for most users.) > > If we see maintaining comps as too much of a burden (which is somewhat true, > because it requires touching files outside of the packages, which has become > even more tedious when the move to Pagure removed write permissions to the > comps repository from almost all packagers, forcing us to go through pull > requests), This is, however, a major win in another regard: we can stop people breaking comps during freezes. Which *did* happen. Quite often. We've more than once had a candidate compose fail or have a release-blocking bug because someone tried to change kickstarts or comps during the freeze, and got it wrong. That kinda points up a problem in that we have a single thing - comps - which serves multiple roles with kinda different requirements. It's not *really* a big problem to anyone if some group which is not included on any media, and just exists to be shown in package managers like dnfdragora, has some bad entries in it. It's absolutely a problem if someone decides to change @core or @anaconda-tools or @workstation- product and gets it wrong. It's kinda bad that these things have to be in the same project, in the same *file*, and thus subject to the same policies for modification, with the result that there's always going to be some suboptimal result (either making it too easy to change the really important stuff, or too hard to change the unimportant stuff). > then we should just undeprecate the RPM Group tag and move back > to that. Dnfdragora already supports Group tags out of the box. (In fact, > moving to them would allow Dnfdragora upstream to remove the special-case > code for Fedora.) > > The rationale for deprecating RPM Group tags was that comps should be used > instead. But if we want to get rid of that use of comps (since a comps > without optional packages is no longer a suitable replacement for Group > enumeration! A lot of packages that users will want to install will not be > listed there anymore), what speaks against using Group again? > > So I see only 2 alternatives: > a) keep comps as it is now, including optional packages, OR > b) undeprecate the RPM Group tag, readd it to all Fedora packages, and > switch back to it. > Any other plan will completely break Dnfdragora. That's a fair point. I didn't really follow the 'no group tags' proposal closely and hadn't noticed it suggested comps as an alternative. But at the same time I think Matt's right that comps -at least as it's currently set up - is kind of a really *bad* way of doing this, and that seems fairly well demonstrated by the problem I'm trying to solve - that comps has tons of broken entries in it. Just from looking through the file as I do this, I really suspect that no-one is maintaining quite a lot of the groups and the packages in them may well just not make much sense any more. Of course, inventing some kind of Third Way requires someone to commit the time to doing that, and I'm not sure I'm gonna have that right now. So perhaps we can do something somewhat less drastic, like trimming some of the groups and throwing away ones that are clearly not maintained any more, like the scientific lab one. Another idea that occurred to me is that we could perhaps sneak in a sort of 'rings-lite' concept by splitting up comps. We could split up the bits into maybe three chunks: 1. bits that are basically there as compose glue - groups that aren't user-visible but *are* pulled into compose deliverables 2. critical user-visible groups that are often also part of the compose, like the Edition groups and environments, the kde group, the xfce group 3. Less important user-visible groups that just aren't that significant and don't constitute part of the compose, or at least not the release- blocking bits Something like that. Then the bits could have different access policies. All this would really require would be some kinda little script to merge the necessary bits when running composes, I guess... -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
