> Am 31.01.2023 um 23:39 schrieb Adam Williamson <adamwill@xxxxxxxxxxxxxxxxx>: > > Hey folks! > > I've sort of happened into doing some maintenance of fedora-comps over > the last few years. Something that bugs me while working on this is how > many "shopping list" groups we still have. I'm talking about things > like the network-server group: > ... I would very much appreciate it if we would start to review and clean up comps. Problem are not only these "shopping lists", but also e.g. various Fedora Server Edition related items. Regarding network-server, this group is in my opinion much too divergent and at least currently conceptually superfluous . But e.g. environment Cloud Server & infrastructure-server use them. But none of the kickstart files. The group would be a candidate for deletion. But tracing the effects is likely to be painful. > I'd define a "shopping list" group as one based around a vague theme > and whose packages are all (or almost all) optional - it's clearly not > a group that's meant to be installed as a whole, or as a part of a > system deployment. These groups were instead designed as lists to pick > individual packages from, in the old anaconda installer interface that > let you do individual package selection (this is, what, a decade or so > ago now?), and in software installation apps that similarly let you > pick packages from the comps groups. > > Neither GNOME Software nor KDE Discover uses these "shopping list" > groups. (The older GNOME tool that preceded Software did, I think; > again, that was years ago now). However, dnfdragora (which is the main > package manager on some smaller desktops, and may still be installed on > KDE alongside Discover by default, I'm not sure) *does* - you can > browse by comps group (and 'category', which are collections of comps > groups intended for this purpose, different from the 'environments' > used by anaconda) in dnfdragora. Maybe some other GUI packaging tools > do as well, I'm not sure of any others to check. > > It does not appear to me like anyone besides me does much maintenance > on these groups. For instance, I don't think anyone but me has touched > the network-server group since 2019. > > These are the groups I'd identify as "shopping list groups": > > cloud-infrastructure > directory-server > dns-server (one 'default' package) > editors > education > ftp-server (one 'mandatory' package) > games (the games spin does not use this group, it has its own list) > graphical-internet > graphics > legacy-network-server > libreoffice-development > network-server > neuron-modelling-simulators > news-server (one 'mandatory' package) > office > server-cfg (one 'default' package) A good candidate for deletion, too. As far as I see it is used in category servers, but not in any kickstart. „servers“ itself is quite divergent and probably another kind of „shopping list“. > ... > definition but are still of rather dubious usefulness, like the 'web- > server' group which is rather stuck in the 2000s (including php, php- > ldap, php-mysqlnd, squid and webalizer by default - is this how anyone > "deploys a web server" these days?) >From a Fedora Server point of view it is superfluous, but it is used in 4 other entries, which are also rather too divergent and superfluous (e.g. web-server-environment). > So, I'm wondering what folks think we should do with these. We could, > of course, just get rid of them. But perhaps they are still of value to > someone? Is anyone still "package shopping" via dnfdragora or some > other tool, using these groups? Does anyone want to step up and > actively 'own' some of them for maintenance? Any other thoughts? I would really prefer to get rid of those. _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
