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

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

 



On Wed, Sep 26, 2018 at 12:36 PM Adam Williamson
<adamwill@xxxxxxxxxxxxxxxxx> wrote:
>
> On Tue, 2018-09-25 at 08:17 +0200, Vít Ondruch wrote:
> >
> > Dne 24.9.2018 v 19:32 Adam Williamson napsal(a):
> > > On Mon, 2018-09-24 at 12:21 +0200, Vít Ondruch wrote:
> > > > Just FTR, some while ago, I proposed to drop comps entirely:
> > > >
> > > > https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx/message/ISCIB67JKW7WBC74KA4DSCAP6AZOUY5G/
> > > That...doesn't seem like a very serious proposal at all, given that you
> > > didn't suggest *in any way* how we would replace the critical functions
> > > it's currently performing. Are you suggesting metapackages?
> >
> > Well I proposed "drop comps entirely (or at least trim them down
> > significantly)". At least the second part is in line with your request I
> > believe.
> >
> > And I am not speaking necessarily about "metapackages". But we should
> > really start using Recommends more and especially Suggest is unused at
> > all. E.g. in comps, there is "Ruby on Rails" group installing bunch of
> > packages. There is no reason to not have these dependencies specified in
> > rubygem-rails (which already exists and has its purpose no matter if
> > there are comps or not) via Suggests for example. The only issue AFAIK
> > is there is no real support for Suggests in DNF :/
>
> How would this work in the identified use case of 'package managers
> displaying groups of packages for browsing'? Would the package managers
> have to somehow generate these views on the fly from Suggests?

libsolv can generate special solvables when packages are tagged
correctly, which could be exposed through the DNF API such that
dnfdaemon can identify it as a "group" type and represent them
specially. This is how patterns work in (open)SUSE with Zypper.

But actually, I'd rather not go to that, because the composition
groups based categorization is too weak and incomplete when it comes
to sorting packages for people to browse (which is what dnfdragora
does).

This is why I'd advocate for the return of the RPM Group tag, because
it's a useful way to categorize the entire collection of packages.

But if we insist on comps-style grouping *only*, then we could do that
with metapackages. We can also do it to some extent with AppStream
data, but again, that's incomplete from the perspective of the
distribution as a whole. It's not useful enough for a package manager
view, though it's certainly good for an app-centric view.


--
真実はいつも一つ!/ 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