System-wide uBlue Location
Has there been any prior implementation or discussion about a place to store uBlue-related files that need to exist on the system, in an immutable, shared location?
There is a now need to fix an issue in uBlue-startingpoint's "autostart" script. It's currently being copied into every user folder once and then never again. Meaning that future fixes never get applied to it. It's very rigid.
I've got a solution but need a systemwide location to store the code in a shared location for all users.
What are your thoughts about this?
22 Replies
@j0rge @.jstone @KyleGospo @marcoceppi @hermmm
Let's discuss this a bit. Chime in with any other ideas you have, when you have time. š
So far it seems like we've only been using files intended to be consumed by other programs which already have a standardized location. But we're gonna need one of our own, for various uBlue doodads to live in. š
There is no hurry on this, the feature that needs it can be implemented later in a backwards-compatible way. But let's get the ball rolling. š
To avoid components stepping on each other, especially if they contain many files, we should definitely have sub-project folders. That way everyone can work on component projects without worrying about overwriting other files by accident.
Here's an idea for a structure:
So for our current needs, with "update service", the "first boot" files and the global "just" config, it would look like this:
We may also want to specify that the sub-project folders shouldn't contain the name
ublue since it sounds a bit too repetitive and long-winded?
Compare /usr/share/ublue-os/ublue-os-update-services vs the cleaner /usr/share/ublue-os/update-services? It's already clear that the sub-folders belong to ublue without repeating it twice. Even if it's part of the sub-project's official name, it would still be overkill in the system folder hierarchy, and would require extra typing/<tab>-completion in the shell.
Anyway... this was just meant to start the discussions. Looking forward to hearing your ideas. šHow would the changes be handled from let's say, Fedora 37 to 38 or Fedora 36 to 38 in those configs? Configs would need to be updated to support upgrade from those, or it automatically knows what needs to be added & removed?
These files are bundled inside the image at the system level, so you'll always automatically have the exact config that shipped with the image (Fedora version) that you're running. š They aren't user-editable.
This is just about figuring out a good, unified location to store the growing list of things (helper scripts, example configs, etc) that uBlue needs to add to the system. Currently they are scattered all over the place.
So far from what I read, your suggestion is good. Have nothing in my mind to improve.
But I'm noob, so eh.
@j0rge I just spotted something:
https://github.com/ublue-os/main/blob/main/post-install.sh
So there is already a precedent for using the folder I proposed. I also think it makes the most sense.
The only thing that I would suggest is that we avoid folder-name repetition, as mentioned earlier, so the post-install could use this instead:
yeah we have different stuff spread out in places, which is why I recommend that this gets whipped up into a proposal so we can all read it
we strongly prefer design discussions in github and not here
I have a proposal above:
https://discord.com/channels/1072614816579063828/1105686489314107463/1105688559173779466
Which issue tracker do you want it at? /main?
stick it in the forum and add the "proposal" label
GitHub
Build software better, together
GitHub is where people build software. More than 100 million people use GitHub to discover, fork, and contribute to over 330 million projects.
then just edit it as people leave comments
Nice, will do š
I've got some calls today but will check it out this afternoon!
@bsherman about to get on a call with a podman person, seeing if we can get that examples repo going
No problem. There's no hurry on this. Everything can be moved smoothly when it's time without issues on existing systems. š
Here's a nicely formatted proposal:
https://github.com/orgs/ublue-os/discussions/149
Sweet, good luck! š
This bug is probably a reason why I could not get gnome-vrr update, so I had to do full reinstall of it
I changed the name of the repo iirc from initial one
I thought back than that f37 in the name would make problems, so I changed it to generic one
You may be thinking of the rpm-ostree bug? Yes that's the reason why you couldn't get that update. Do you have a github account? If so, add your comment here to mention that this bug affected you, they would appreciate seeing real-world emergencies like this to gauge interest:
https://github.com/coreos/rpm-ostree/issues/4403
GitHub
rpm-ostree does not read
/usr/lib/yum.repos.d [update: ticket bel...Greetings! :) Thanks to the emerging support for OCI images at the operating system level, there's a growing number of users who layer images on top of each other. This presents new issues with...
Alright, I will
Thanks, it helps. š ā¤ļø
Done
Thank you, that's a nice message. I appreciate your help. š We have the interest of one of the lead maintainers of rpm-ostree/libdnf ("cgwalters" in the thread), and now your anecdote to show the real-world need for this. Excellent. š
I don't think the repo name was the issue with that one
Changing the repo file name & repo content itself is indeed different
Indeed but I didn't feel like pointing it out. It's still a fine, semi-related comment, hehe. š
Either way, cgwalters tagged the ticket as
triaged which is a very rare honor (https://github.com/coreos/rpm-ostree/labels/triaged), so there's a good chance they'll consider this a priority issue. In the meantime, we can chill since there probably aren't any current ublue users who edit those repo files to break their system upgrades. Although that thought makes me think of one "common" scenario that can trip people up... Edit: Added that scenario - https://github.com/coreos/rpm-ostree/issues/4403#issuecomment-1542385907