On Sat, Sep 22, 2018 at 2:39 PM Adam Williamson <adamwill@xxxxxxxxxxxxxxxxx> wrote: > > 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. > Personally, as dnfdragora upstream, I'd definitely prefer if we killed special cases like this. > 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. > Actually, we might want to consider adopting a variant of SUSE's approach. Their "patterns" used to work the same way our comps do now. However, they made the transition from externally developed and separately injected metadata to being generated from specially set up metapackages. Those metapackages could be controlled by the same kind of ACLs we have now for regular packages, and they could be used as the input to automatically generate comps.xml data, as SUSE does for generating pattern info (for versions of SUSE Linux that don't automatically map pattern requests to metapackage install requests). This would have the added advantage of simplifying our repodata creation process and allow people the flexibility to define their own in a way that the package manager can easily pick up. The only downside to us dropping comps.xml metadata is the loss of translations, unless we support the rpmmd extension SUSE developed for translating package data. I suppose we'd also lose the "inheritance merge" model of comps across repos, but I'm not sure that was a good idea to begin with... (Which of course means we really have to actually standardize the extension so that all the tools can handle it coherently... I don't even know how SUSE creates the susedata.xml data currently, and it obviously can't be called susedata.xml anymore!) The combination of the RPM Group tag and groups defined via special metapackages would give everyone the same level of flexibility while allowing the distribution to maintain some stability in the core parts that make the composed released "work". -- 真実はいつも一つ！/ Always, there's only one truth! _______________________________________________ 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
