On 04/04/2016 12:10 PM, Zbigniew Jędrzejewski-Szmek wrote:
Hi,
I'd like to move two systemd subpackages from the the @core group,
but I don't know where to move them to.
systemd-udev must be installed on "real hardware", so it must be
part of Workstation, Server, Cloud, and any spin. It should not be
installed in containers and chroots, e.g. mock.
Is @standard the right place? (Or @hardware-support?)
systemd-container should probably be installed in full Server installations.
Should I just move it to @virtualization-headless?
Zbyszek
PS. That's be for F24+.
I think part of this may be a discussion for the Modularization WG. I was
planning to start a conversation about retiring the @standard group entirely and
moving towards a set of functional groups rather than trying to have catch-all ones.
For example, I wrote in in
https://bugzilla.redhat.com/show_bug.cgi?id=894110#c18 today:
"I'm personally of a mind that the @standard group should be entirely retired in
favor of a series of functional groups that the various editions and spins would
pull in. Which sounds a lot like... modules.
@standard (and @core) have a lot of history built primarily around the idea that
there was *one* Fedora deliverable and so those two groups attempted to
accommodate everyone (succeeding at accommodating essentially no one). It's time
they were retired."
Also, there's a ton of cruft in comps.xml that is just archaic and out of date.
There are many packages referenced in it that have been retired over the years
and there is a lot of duplicated content. My proposal to devel@ is that we
should basically rework comps.xml entirely. I'd like to see us break comps up as
sort of a prototype of modules and then have us construct the Environment Groups
from these modules.
For some examples: instead of @standard containing everything from btrfs-progs
and tar to wireless-tools, I think we should retire it and instead offer modules
such as @filesystem-tools, @archive-tools and @wifi-support. This will also make
it possible to more finely-tune each of the Editions and Spins (and may help
shrink down the Atomic Host as well).
(Also, going forward I'd love to see us build comps in a more sane manner than
by editing an XML file; this simply *screams* for having a decent web UI to
manage it, tied into pkgdb so when a package is retired it also disappears from
comps).
All that said, for F24 I think @standard is probably the right place for
systemd-udev. But I think comps needs to be completely rethought in F25+.