4:39 p.m.
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:
<id>network-server</id>
<_name>Network Servers</_name>
<_description>These packages include network-based servers such as DHCP,
Kerberos and NIS.</_description>
<default>false</default>
<uservisible>true</uservisible>
<packagelist>
<packagereq type="optional">389-ds-base</packagereq>
<packagereq type="optional">ahcpd</packagereq>
<packagereq type="optional">amanda-server</packagereq>
<packagereq type="optional">babeld</packagereq>
<packagereq type="optional">cobbler</packagereq>
<packagereq type="optional">dhcp-relay</packagereq>
<packagereq type="optional">dhcp-server</packagereq>
<packagereq type="optional">dnsmasq</packagereq>
<packagereq type="optional">freeradius</packagereq>
...etc etc...
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)
sound-and-video
text-internet
window-managers
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?
Thanks folks!
--
Adam Williamson (he/him/his)
Fedora QA
Fedora Chat: @adamwill:fedora.im | Mastodon: @adamw(a)fosstodon.org
https://www.happyassassin.net
7:18 p.m.
On Tue, Jan 31, 2023 at 02:39:27PM -0800, Adam Williamson wrote:
Hey folks!
...snip...
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'd be in favor of removing them (of course with a change and giving
notice, etc).
kevin
11:47 p.m.
On Jan 31, 2023, at 2:39 PM, Adam Williamson
<adamwill(a)fedoraproject.org> wrote:
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 stumbled into a similar thing recently for the Amazon Linux version of comps. It’s had
the benefit of at least one time going “oh, we shall start from scratch here and not have
the accumulated cruft over the past <years>!”, but the disadvantage of growing its
own (unique!) cruft.
We have notably fewer sections that are shopping lists, but do find value in the groups
for things that are groups for specific types of images. So we have a “container” group
which is what the image recipe for the container image installs, same with “ami-minimal”
and “ami” for the standard and minimal AMIs respectively. This lets us do nice things such
as modify that over time, not require image recipe updates for every possible change etc.
The most notable being that (in the ideal scenario, which is the normal case), the content
of each of these images for a particular snapshot of the repo is already built into the
repo.
<id>network-server</id>
<_name>Network Servers</_name>
<_description>These packages include network-based servers such as DHCP,
Kerberos and NIS.</_description>
<default>false</default>
<uservisible>true</uservisible>
<packagelist>
<packagereq type="optional">389-ds-base</packagereq>
<packagereq type="optional">ahcpd</packagereq>
<packagereq type="optional">amanda-server</packagereq>
<packagereq type="optional">babeld</packagereq>
<packagereq type="optional">cobbler</packagereq>
<packagereq type="optional">dhcp-relay</packagereq>
<packagereq type="optional">dhcp-server</packagereq>
<packagereq type="optional">dnsmasq</packagereq>
<packagereq type="optional">freeradius</packagereq>
...etc etc...
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.
I wonder if anyone has used any of them since 2019? :)
I can’t really think of a way to find this out though.. short of doing some hefty
gymnastics around package download logs...
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)
sound-and-video
text-internet
window-managers
If it helps as a data point, we don’t have any of these groups in Amazon Linux and nobody
has *ever* asked for them (well.. maybe *once*…)
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?
Delete them all!
I can’t think of a modern usage that isn’t geared towards the image-type scenario I
describe above.
1:14 a.m.
Am 31.01.2023 um 23:39 schrieb Adam Williamson
<adamwill(a)fedoraproject.org>:
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.
1:37 a.m.
On Wed, 2023-02-01 at 08:14 +0100, Peter Boy wrote:
> Am 31.01.2023 um 23:39 schrieb Adam Williamson <adamwill(a)fedoraproject.org>:
>
> 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.
Well, some environments do list some of the "shopping list groups",
yes. But unless someone's aware of something I'm not, this is
effectively pointless except in one extremely unusual scenario.
Putting a group in an environment's grouplist or optionlist, in most
cases, can only pull in its default and mandatory packages. In any
typical case, it does not pull in any of its optional packages. So if a
group contains *only* optional packages, it's almost entirely pointless
to put it in an environment.
The only exception of this I'm aware of is if you do a kickstart
install and use the --optional setting. You can theoretically write a
kickstart like this:
%packages
<blahblah whatever you like>
@network-server --optional
%end
...and that will pull in everything in the network-server group. But I
can't imagine anyone *actually* does this. These groups clearly aren't
set up with the intention that anyone would want to install
*everything* in them. They were clearly intended for 'shopping'.
So, as part of the "get rid of them" option, we would also drop them
from the environments (and categories) they are listed in. None of them
is listed in any grouplist, they are only in optionlists.
In a way this kinda naturally leads into the question of whether we
should maintain the categories, which are specifically intended for
package shopping. If we start getting rid of package shopping groups,
keeping the categories around makes less sense, I guess.
> 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“.
Yes, see above. The categories are basically like environments, but
specifically for "package shopping" (in fact categories came first and
environments later, but never mind). That's all they exist for -
they're really kinda "UI cues"; a package shopping UI is cued to give
you something like a tree view of the categories, you expand a category
to see all the groups in it. Again, I think the old anaconda packaging
UI and gnome-packagekit used this, and dnfdragora still does; current
KDE and GNOME application installer GUIs do not use it.
> ...
> 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).
See above; their inclusion in these environments is likely almost
entirely pointless.
--
Adam Williamson (he/him/his)
Fedora QA
Fedora Chat: @adamwill:fedora.im | Mastodon: @adamw(a)fosstodon.org
https://www.happyassassin.net
2:59 a.m.
Hello,
On Tue, Jan 31, 2023 14:39:27 -0800, Adam Williamson wrote:
snip
neuron-modelling-simulators
We only added this to allow users do use a groupinstall to install all
their modelling related tools in one go. It isn't intended for use in
anaconda. So, happy to remove it, but is there another way of allowing
users to pull in all these packages at once? Should we use a meta
package instead of a comps group (or have I misunderstood how dnf
package groups work)?
--
Thanks,
Regards,
Ankur Sinha "FranciscoD" (He / Him / His) |
https://fedoraproject.org/wiki/User:Ankursinha
Time zone: Europe/London
9:51 a.m.
On Wed, 2023-02-01 at 08:59 +0000, Ankur Sinha wrote:
Hello,
On Tue, Jan 31, 2023 14:39:27 -0800, Adam Williamson wrote:
> snip
> neuron-modelling-simulators
We only added this to allow users do use a groupinstall to install all
their modelling related tools in one go. It isn't intended for use in
anaconda. So, happy to remove it, but is there another way of allowing
users to pull in all these packages at once? Should we use a meta
package instead of a comps group (or have I misunderstood how dnf
package groups work)?
I'd say you've misunderstood how comps groups work, because all the
packages are tagged as optional, which means people need to use an
obscure option to a kickstart or dnf to install them. If you indeed
want a normal 'dnf groupinstall neuron-modelling-simulators' or
'@neuron-modelling-simulators' in a kickstart to install all the
packages, they should be set to 'default' or 'mandatory', not
'optional'. The difference between 'default' and 'mandatory' is
that if
a package is listed as 'mandatory', it *must* remain installed for dnf
to consider the group as 'installed'. If it's listed as 'default', it
will be installed by default when the group is, but can be removed
without the group being considered to have been removed.
--
Adam Williamson (he/him/his)
Fedora QA
Fedora Chat: @adamwill:fedora.im | Mastodon: @adamw(a)fosstodon.org
https://www.happyassassin.net
9:59 a.m.
Once upon a time, Adam Williamson <adamwill(a)fedoraproject.org> said:
The difference between 'default' and 'mandatory' is
that if
a package is listed as 'mandatory', it *must* remain installed for dnf
to consider the group as 'installed'. If it's listed as 'default',
it
will be installed by default when the group is, but can be removed
without the group being considered to have been removed.
Jumping in because this brings a question to mind: does dnf thinking a
group is installed mean anything? For example, let's say comps is
changed to add a package (default/mandatory) to a group - will dnf say
"a-ha, I have this group installed, I need to add this package"?
If not... would that be desirable behavior?
--
Chris Adams <linux(a)cmadams.net>
10:18 a.m.
On Wed, 2023-02-01 at 09:59 -0600, Chris Adams wrote:
Once upon a time, Adam Williamson <adamwill(a)fedoraproject.org>
said:
> The difference between 'default' and 'mandatory' is that if
> a package is listed as 'mandatory', it *must* remain installed for dnf
> to consider the group as 'installed'. If it's listed as
'default', it
> will be installed by default when the group is, but can be removed
> without the group being considered to have been removed.
Jumping in because this brings a question to mind: does dnf thinking a
group is installed mean anything? For example, let's say comps is
changed to add a package (default/mandatory) to a group - will dnf say
"a-ha, I have this group installed, I need to add this package"?
I believe it does do that on upgrades when a group is marked as
installed, yes. In the past there was an issue where groups weren't
marked as installed when installing from a live image (so e.g. after
installing from the Workstation live, the 'gnome-desktop' group wasn't
marked installed), but I believe that finally got resolved somewhere
along the way, so will only affect older, long-upgraded installs now.
--
Adam Williamson (he/him/his)
Fedora QA
Fedora Chat: @adamwill:fedora.im | Mastodon: @adamw(a)fosstodon.org
https://www.happyassassin.net
11:07 a.m.
Dne 01. 02. 23 v 17:18 Adam Williamson napsal(a):
On Wed, 2023-02-01 at 09:59 -0600, Chris Adams wrote:
> Once upon a time, Adam Williamson <adamwill(a)fedoraproject.org> said:
>> The difference between 'default' and 'mandatory' is that if
>> a package is listed as 'mandatory', it *must* remain installed for dnf
>> to consider the group as 'installed'. If it's listed as
'default', it
>> will be installed by default when the group is, but can be removed
>> without the group being considered to have been removed.
> Jumping in because this brings a question to mind: does dnf thinking a
> group is installed mean anything? For example, let's say comps is
> changed to add a package (default/mandatory) to a group - will dnf say
> "a-ha, I have this group installed, I need to add this package"?
I believe it does do that on upgrades when a group is marked as
installed, yes.
Interesting. I sometimes stumble upon something like "Installing
packages/groups" during updates and I always wondered why. Need to
observe this next time.
Vít
In the past there was an issue where groups weren't
marked as installed when installing from a live image (so e.g. after
installing from the Workstation live, the 'gnome-desktop' group wasn't
marked installed), but I believe that finally got resolved somewhere
along the way, so will only affect older, long-upgraded installs now.
10:04 a.m.
On Wed, Feb 01, 2023 07:51:08 -0800, Adam Williamson wrote:
snip
I'd say you've misunderstood how comps groups work, because
all the
packages are tagged as optional, which means people need to use an
obscure option to a kickstart or dnf to install them. If you indeed
want a normal 'dnf groupinstall neuron-modelling-simulators' or
'@neuron-modelling-simulators' in a kickstart to install all the
packages, they should be set to 'default' or 'mandatory', not
'optional'. The difference between 'default' and 'mandatory' is
that if
a package is listed as 'mandatory', it *must* remain installed for dnf
to consider the group as 'installed'. If it's listed as 'default',
it
will be installed by default when the group is, but can be removed
without the group being considered to have been removed.
Ah, that explains it. I think we need to probably use "default" there
then. I'll discuss it with the neuro-sig and open a PR.
--
Thanks,
Regards,
Ankur Sinha "FranciscoD" (He / Him / His) |
https://fedoraproject.org/wiki/User:Ankursinha
Time zone: Europe/London
448
days inactive
449
days old
10 comments
7 participants
participants (7)
-
Adam Williamson -
Ankur Sinha -
Chris Adams -
Kevin Fenzi -
Peter Boy -
Smith, Stewart -
Vít Ondruch