On Wed, 2022-10-19 at 14:29 -0400, Josh Boyer wrote: > On Tue, Oct 18, 2022 at 9:37 AM Matthew Miller <mattdm@xxxxxxxxxxxxxxxxx> wrote: > > > > On Sun, Oct 09, 2022 at 05:17:29AM +0200, Kevin Kofler via devel wrote: > > > IMHO, we need a proper solution for the general comps issue rather than that > > > half-baked compromise that does not really improve the situation. KDE Plasma > > > > I agree -- comps has a lot of problems which limit our flexibility, and > > doesn't really even expose useful collections to users. I'd love to see a > > modern replacement. > > I think it would be interesting to replace it with Colin's OS > Container ideas. Want KDE? Install the KDE OS container layer. > Creation of that is in a container file. > > That's a departure from traditional installations, but it's still > interesting. The rub here is that comps isn't well loved, but it's > not very complicated either. It's a list of packages associated with > a thing, and our tools know how to interpret it. A modern replacement > for "a list of things" by itself isn't going to be very ground > breaking. Changing how we think about and deploy the OS gives us more > interesting options. well, this was strictly speaking more a feature request for libcomps: what Kevin really wants, I think, is to be able to do something like this... <packagereq type="conditional" requires="kde-desktop-environment">kde-partition-manager</packagereq> <packagereq type="conditional" requires="workstation-product-environment">gnome-disks</packagereq> note, this syntax exists already, but - AFAIR - you can only put package names as the 'requires' property. If you could put comps groups and environment groups there, you could actually do what Kevin wants. The idea of "replacing comps" is kind of a tricky one, because it's used for a lot more stuff than you might immediately realize. It is, as you say, just a big list of things, and definitions like "these are the things that make up a Fedora Workstation environment" turn out to be really useful, so we use them all over the place. For instance, the desktop rpm-ostree manifests live here: https://pagure.io/workstation-ostree-config/tree/main but how do they get generated? welp...from comps: https://pagure.io/workstation-ostree-config/blob/main/f/comps-sync.py we can, of course, port things off comps bit by bit, but the danger I see there is that we wind up with ten different lists of the same things in different places. If anything, the direction of travel over the last few years has been towards *reducing* duplication and trying to put all the lists in comps; one thing we did a few years back was make it so liveimage-creator could use comps environment group definitions, so we could just put `@^workstation-product-environment` in the Workstation live image kickstart instead of effectively duplicating the definition of workstation-product-environment in the kickstart: https://pagure.io/fedora-kickstarts/c/dd8d0fa2028f42a4500aa779382b11e617a76491?branch=main and I think there's something to be said for that approach. XML isn't cool any more, but comps/libcomps do the job they're intended for pretty well, and that job is relevant to building cool new stuff as well as cool old stuff. I like Colin's native container ideas too, but I'm not sure it's an improvement to duplicate the list-of-KDE-bits in "a container file", as opposed to the container file's instruction just being "install the kde-desktop-environment group"... -- Adam Williamson Fedora QA IRC: adamw | Twitter: adamw_ha https://www.happyassassin.net _______________________________________________ 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
