What should we do about "shopping list" groups in comps?
by Adam Williamson
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:
<_description>These packages include network-based servers such as DHCP, Kerberos and NIS.</_description>
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":
dns-server (one 'default' package)
ftp-server (one 'mandatory' package)
games (the games spin does not use this group, it has its own list)
news-server (one 'mandatory' package)
server-cfg (one 'default' package)
there are a few other groups that don't fit strictly into the
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?) Being stuck in the 2000s is kind of
a defining feature of these groups - any time you see a vaguely modern
package, it's probably been put there by me, replacing something that
got orphaned. Otherwise most of them seem to have been defined back
then and rarely or never updated since. (Another example: the last time
the 'games' group was updated by anyone but me was 2017, adding one
game; the last update before that seems to have been in 2013).
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?
Adam Williamson (he/him/his)
Fedora Chat: @adamwill:fedora.im | Mastodon: @adamw(a)fosstodon.org
Proposed change to rendering of release schedule ics file
by Ben Cotton
I want to get feedback before I make a change to how Fedora Linux
schedules are generated. As reported in schedule#91, the current
ics files include very long tasks that aren't particularly useful. I
have a plan for how to address that, but first I want to check that it
won't impact how people currently use the ics files.
If you're using the Fedora Linux schedule ics files, please see the
details in the Pagure issue. If this will affect how you or your
team use those files, comment in the issue before 13 February. Note
that this will not change how the html or json versions are produced.
He / Him / His
Fedora Program Manager