In going through the bugs against comps, I came across https://bugzilla.redhat.com/show_bug.cgi?id=1971338
The "admin-tools" group in comps includes GNOME Disks, which is a surprise for KDE Plasma users. We can swap it out for blivet-gui (note that other groups for GTK-based desktops would still include GNOME Disks) easily enough, but I didn't want to do that without seeking comment.
Does anyone have a good reason we shouldn't make this change?
(I don't think this rises to the level of requiring a Self-Contained Change proposal, but I'm happy to submit one if the consensus is that it should have one)
On Wed, Oct 05, 2022 at 02:22:52PM -0400, Ben Cotton wrote:
In going through the bugs against comps, I came across https://bugzilla.redhat.com/show_bug.cgi?id=1971338
The "admin-tools" group in comps includes GNOME Disks, which is a surprise for KDE Plasma users. We can swap it out for blivet-gui (note that other groups for GTK-based desktops would still include GNOME Disks) easily enough, but I didn't want to do that without seeking comment.
Does anyone have a good reason we shouldn't make this change?
(I don't think this rises to the level of requiring a Self-Contained Change proposal, but I'm happy to submit one if the consensus is that it should have one)
+1 to just do it. I don't think it needs a change.
kevin
On Wed, Oct 5, 2022 at 8:23 PM Ben Cotton bcotton@redhat.com wrote:
In going through the bugs against comps, I came across https://bugzilla.redhat.com/show_bug.cgi?id=1971338
The "admin-tools" group in comps includes GNOME Disks, which is a surprise for KDE Plasma users. We can swap it out for blivet-gui (note that other groups for GTK-based desktops would still include GNOME Disks) easily enough, but I didn't want to do that without seeking comment.
Does anyone have a good reason we shouldn't make this change?
(I don't think this rises to the level of requiring a Self-Contained Change proposal, but I'm happy to submit one if the consensus is that it should have one)
Makes sense to me. +1
Ben Cotton wrote:
In going through the bugs against comps, I came across https://bugzilla.redhat.com/show_bug.cgi?id=1971338
The "admin-tools" group in comps includes GNOME Disks, which is a surprise for KDE Plasma users.
That is just a symptom of a core issue with comps, that the applications in non-desktop-environment groups are not conditional on the user's desktop environment in any way.
This affects much more than just GNOME Disks and the admin-tools group. Pretty much all comps groups except the KDE ones are filled with GNOME apps as mandatory or default, and the KDE equivalents as optional if even listed at all.
We can swap it out for blivet-gui (note that other groups for GTK-based desktops would still include GNOME Disks) easily enough, but I didn't want to do that without seeking comment.
That is still a GTK application though. KDE Plasma users will want KDE Partition Manager instead.
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 users should get KDE applications by default everywhere.
Kevin Kofler
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.
On Tue, Oct 18, 2022 at 9:37 AM Matthew Miller mattdm@fedoraproject.org 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.
josh
On Wed, 2022-10-19 at 14:29 -0400, Josh Boyer wrote:
On Tue, Oct 18, 2022 at 9:37 AM Matthew Miller mattdm@fedoraproject.org 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/dd8d0fa2028f42a4500aa779382b11e617a764...
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"...
Josh Boyer wrote:
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 does not even come close to fulfilling all the use cases comps is for. A comps group can both be used to create images (including container images) and be installed at any time on an existing system. This is much more flexible than just having to install a whole new container for every desktop environment you want to use.
That's a departure from traditional installations, but it's still interesting.
Not for me, sorry.
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.
But it ultimately still needs to be "a list of things", you cannot replace apples with oranges as you seem to suggest. (And at that point, I see no point in redoing comps from scratch, we just need to improve what is already there, adding the missing features, and then actually making use of them.)
Changing how we think about and deploy the OS gives us more interesting options.
But "changing how we think about and deploy the OS" is not what this thread is about!
I am fed up of containers being constantly sold as the one-size-fits-it-all solution to all our problems, even where it is completely off topic.
(And ultimately, replacing a system of package groups with one of "take it or leave it" containers would give the end user *fewer* options, not more. The package groups can easily be used to compose containers, but not the opposite.)
Kevin Kofler
Am 09.10.22 um 05:17 schrieb Kevin Kofler via devel:
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 users should get KDE applications by default everywhere.
On what criteria does the algorithm decide which package to install, if the system it should judge on, has more than one DE installed?
Example:
I have 4 DEs installed: openbox, gnome, cinnamon and kde
Now the installing root user logs in via ssh and all the fantasies about reading out the used DE from the loggedin user become null and void. To make it short: there is no 100% to be sure way to automatically decide what to install, except...
Solution:(Example)
admin-tools-kde admin-tools-gnome admin-tools-cinnamon admin-tools-openbox admin-tools-i3 ...
with overlapping packagelists and DE dependend choices.
The installation requirements is than the fact, if the DE is installed or not.
best regards, Marius Schwarz
Marius Schwarz wrote:
On what criteria does the algorithm decide which package to install, if the system it should judge on, has more than one DE installed?
It installs the packages for all the installed desktop environments, even if their functionality overlaps. If you choose to install both KDE Plasma and GNOME, you should get both KDE applications and GNOME applications by default. If you have 4 DEs installed, you should get applications for all 4 of them by default (where they differ to begin with, so, e.g., you would probably get 4 file managers, but only 2 partitioners).
Kevin Kofler