Proposal: Drop comps

Vít Ondruch vondruch at redhat.com
Wed Jul 15 08:45:57 UTC 2015


Dne 14.7.2015 v 19:05 Kevin Fenzi napsal(a):
> On Tue, 14 Jul 2015 15:53:49 +0200
> Vít Ondruch <vondruch at redhat.com> wrote:
>
> ...snip...
>
>>>  * The comps.xml groups also provide grouping for
>>> logically-connected packages that do not map to weak dependencies
>>> well. (For example: an "astronomy" group could pull in numerous
>>> scientific packages related to astronomy)
>> We can get back to metapackages, which are still used in Fedora in
>> various forms anyway.
> Metapackages have a lot of downsides too, only a few parts of which are
> made better by weak dependencies. 
>
> See: http://yum.baseurl.org/wiki/YumGroupsOverview

I can't say this document is not confusing. But at least 3 points from
the "cons" section of metapackages could be removed IMO.


>
>>> I don't think there's any sense in removing comps.xml entirely,
>> The problem with comps is that (IMO), it are not widely understand
>> what are they good for, how to manage them, how to change them etc,
>> while the package dependencies are quite well understood.
> So it's an education problem?

How long are comps in Fedora? You can call it educational problem, but
this is just hiding of the problem IMO.

>
>>>  though
>>> I'll be the first to say that it would be great if someone went
>>> through and cleaned it up a bit. There's a lot of old cruft around.
>> Sure, the first step is trimming down. For example, the rubyonrails
>> group could be removed and replaced by appropriate Suggests in
>> rubygem-rails (as soon as DNF supports the appropriate options [1]
>> though).
> I suspect there may be lots of other cases too...

Definitely, this should be first step anyway. Looking into comps, here
is list of candidates:

anaconda-tools
base-x
eclipse
freeipa-server
haproxy
java
mingw32
mongodb
mysql
ocaml
ruby
rubyonrails
smb-server
tomcat
vagrant



Vít



More information about the devel mailing list