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+.
Attachment:
signature.asc
Description: OpenPGP digital signature
-- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx http://lists.fedoraproject.org/admin/lists/devel@xxxxxxxxxxxxxxxxxxxxxxx
