Re: Semi-serious proposal: drop all optional entries from comps

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux