#270 Add Xfce variant "Xfice"
Merged by siosm. Opened by hyperreal.
hyperreal/workstation-ostree-config main  into  main

Download 270.patch

This adds an rpm-ostree Xfce variant, which I've taken to naming "Xfice", as in Xfce + Ice (immutable=frozen). I have a separate GitHub repo that automatically builds an ostree every week, and I host the ostree remote on my server at https://unixcat.coffee/ostree/xfice-desktop.

Let me know if there is anything else I can do to help with testing, builds, etc.

Metadata Update from @siosm:
- Request assigned

Can you make those changes directly to the existing fedora-xfce manifest (and rename it?). You should rebase it for rawhide.

Why do we need to manually specify all of those packages? Aren't they in the comps group?

Can you make those changes directly to the existing fedora-xfce manifest (and rename it?). You should rebase it for rawhide.

Yes, I will do this today.

Why do we need to manually specify all of those packages? Aren't they in the comps group?

I've tried using '@xfce-apps' and such but for some reason it doesn't get expanded during build. I think it's related to these:
- https://github.com/rpm-software-management/libcomps/issues/22
- https://github.com/cgwalters/fedora-atomic-work/commit/36d18b490529fec91b74ca9b464adb73ef0ab462
- https://github.com/rpm-software-management/libdnf/issues/107

Or maybe I was just doing it wrong? Is there a right way to specify comps groups?

Just to be clear: You want me to add the changes from the file fedora-xfice.yaml to the file fedora-xfce.yaml, and then rename fedora-xfce.yaml to fedora-xfice.yaml, and use rawhide instead of f35?

When I commit the changes, should I squash it?

Is there a right way to specify comps groups?

There is no way to do that right now. The comps group should include the packages directly or we can enhance the comps-sync logic to add support for that.

You want me to add the changes from the file fedora-xfice.yaml to the file fedora-xfce.yaml, and then rename fedora-xfce.yaml to fedora-xfice.yaml, and use rawhide instead of f35?

Yes, move everything into a single file and squash all commits. We only need one manifest. The name will have to be vetted for trademarks issues but that can happen later.

We merge changes for Rawhide here and they will appear in F37 when it gets branched. You can maintain your F35 & F36 branches in your fork in the meantime.

Is there a right way to specify comps groups?

There is no way to do that right now. The comps group should include the packages directly or we can enhance the comps-sync logic to add support for that.

As far as I can tell, the xfce-desktop comps group does not contain those packages. This is also something I was hoping for feedback from the community on. Those plugins might be better left for the user to layer over their base install. Utilities like galculator and mousepad I think are good to keep. It looks like there are flatpaks for org.xfce.mousepad and org.xfce.ristretto, but they are from Flathub and not Fedora.

rebased onto 2e054295526a3169759bbab0c76c8ce9b6b02807

We should include everything that is needed for a functional desktop minus the application. Normally, that would be the exact same thing as the XFCE Spin from Fedora. If more packages are needed then the comps need an update.

The only applications that we include in the base image are a web browser, a file manager and optionally an archive manager, to ensure that even without all Flatpaks, users still have a working system that they can use to re-install Flatpaks.

We can not ship Flathub Flatpaks pre-installed on Fedora variants so we need to make Fedora Flatpaks to pre-install them.

Okay, makes sense. The XFCE Spin installs the comps groups @xfce-apps, and I included those apps in the fedora-xfice.yaml file because nothing pulled them in during the ostree compose with the default upstream fedora-xfce.yaml. I figured having a few Xfce-friendly basic utilities like mousepad and galculator included in the ostree would be ideal; however, I can remove all of those and make it nearly identical to the upstream fedora-xfce.yaml while keeping the xfice naming. As for the plugins, those probably don't need to be in the build, so I'll remove those as well.

If all this is okay with you, I will go ahead and push the squashed changes.

We should include everything that is needed for a functional desktop minus the application. Normally, that would be the exact same thing as the XFCE Spin from Fedora. If more packages are needed then the comps need an update.

I'm not sure what you mean by "everything that is needed for a functional desktop minus the application." If it's the exact same thing as the XFCE Spin then it looks like we'd need to update the comps. The default fedora-xfce.yaml didn't include the common XFCE utilities that are normally included in the XFCE Spin.

We can not ship Flathub Flatpaks pre-installed on Fedora variants so we need to make Fedora Flatpaks to pre-install them.

I would be happy to create Flatpaks for common XFCE utilities for Fedora! I've never created a Flatpak before so it should be a fun learning experience. Is there a repository, guide, or docs for contributing Flatpaks to Fedora? So if this is the optimal path, maybe we don't need to update any comps?

Let's recap things a bit.

The comps are what we take packages lists from. It's better if they are complete (as it makes keeping up with package name changes, additions, removal, etc. easier) but it's not critical. Thus if you can clean up the comps then great. Otherwise no big deal.

If you want to include other groups from the comps, you should probably extend the comps-sync script to allow additional groups to be pulled in for each desktops.


Then comes the question of what to include in the base image. The idea is to have a basic working desktop environment with a minimal set of critical applications (basic file editor, web browser, file manager, archive manager). Additional apps should be included as Flatpaks, from the Fedora remote (not from Flathub). If very common apps are not available as Flatpaks then it is also fine to include them in the image until they are packaged as Flatpaks.

Other packages that are part of the desktop environment and that can not be installed as Flatpaks should be installed by default as the default installation should provide a fully working environment and not require additional packages. We don't expect users to use package layering to get basic functionality. That being said, I don't know if this applies to XFCE plugins as I don't know XFCE well.

If it's installed by default in the XFCE Spin then I would say install them by default. We can always remove them later.


I will go ahead and push the squashed changes.

You can directly push squashed changes all the time for this PR.

Is there a repository, guide, or docs for contributing Flatpaks to Fedora?

There is https://docs.fedoraproject.org/en-US/flatpak/ but I'm not sure how up-to-date this is.

rebased onto 04d59c7545d21b783df8c516594f5ec004d28297

If you want to include other groups from the comps, you should probably extend the comps-sync script to allow additional groups to be pulled in for each desktops.

I could do this to include @xfce-apps comps group, as that group contains a web browser and basic utilities like mousepad, galculator, firefox, catfish, geany, ristretto, etc.

The xfce-apps comps group is listed as an optional group, but it is included in the XFCE Spin, so we could include that in the base image if it's reasonable.

So if I understand correctly, I'm going to edit the comps-sync.py script to include xfce-apps comps group? Is there anything else I should know about the comps-sync.py script that would help me in editing it? How do I test the script to ensure it does what it should do?

You can run the script from the repo with a clone of https://pagure.io/fedora-comps. There is currently no automation, this is run manually.

rebased onto f7d38a393603566afa85c279d78f989cb7fb7574

@siosm I've changed comps-sync.py to add xfce-apps to xfce-desktop-pkgs.yaml. Let me know if this is acceptable/optimal.

I'm also wondering if there would ever be a need to check if any packages in xfce-apps are in the comps-sync-exclude-list.yaml so as to exclude them from being added?

rebased onto 2829c953e273234b9fcecbfcc78be177f1a17798

Can you make this change in the script a bit more generic? It would be great to have the logic needed to add any supplemental groups to any desktop for example.

OK, I've given that a try and it does not work well. Taking a look at the list of applications in xfce-apps I think there are more that we don't want than the reverse. So let's keep things as is.

Can you add the packages that you think are missing in the fedora-vauxite manifest directly?

Sorry for the late change again. Hopefully we can get this in.

Or you can try https://pagure.io/workstation-ostree-config/pull-request/280

OK, I've given that a try and it does not work well. Taking a look at the list of applications in xfce-apps I think there are more that we don't want than the reverse. So let's keep things as is.

Can you add the packages that you think are missing in the fedora-vauxite manifest directly?

Sorry for the late change again. Hopefully we can get this in.

Okay, so I've got
- atril (document viewer)
- galculator
- mousepad
- ristretto (image viewer)
- xarchiver

Are these acceptable? Should I include claws-mail as well, or is that not considered essential? Personally I think claws-mail is not used too much and that people generally opt for something like Thunderbird or Evolution or just use the web interface of their email service. But claws-mail is included in the Fedora Xfce Spin base.

Mind you, I'm not saying we should include Thunderbird or Evolution in the base image. Just that I think claws-mail is not worth it.

Okay, so I've got
- atril (document viewer)
- galculator
- mousepad
- ristretto (image viewer)
- xarchiver

This looks like a good list of defaults apps with Firefox until they are all available as Flatpaks.

rebased onto 5bfa251d1bb2e4c490cdc134f341eef19f714e43

Okay, commit has been updated :-)

rebased onto 082755c17ff0568a37ce59cdcffd81036bfe21ab

LGTM. Thanks!

Pull-Request has been merged by siosm

You can "backport" that to F36 if you want too.

Metadata