29 replies

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?

/usr/share/ublue-os/firstboot/ublue-firstboot.desktop

/usr/share/ublue-os/firstboot/ublue-firstboot.desktop

/usr/share/ublue-os/firstboot/ublue-firstboot.desktop

/usr/share/ublue-os/firstboot/ublue-firstboot.desktop

ArcitecOP•5/10/23, 2:47 AM

@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.

ArcitecOP•5/10/23, 2:47 AM

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.

ArcitecOP•5/10/23, 2:51 AM

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:

/usr/share/ublue-os/<sub-project>

/usr/share/ublue-os/<sub-project>

So for our current needs, with "update service", the "first boot" files and the global "just" config, it would look like this:

/usr/share/ublue-os/
├── firstboot
│   └── ublue-firstboot.desktop
└── just-config
    └── justfile
└── update-services
    └── etc
        └── rpm-ostreed.conf

/usr/share/ublue-os/
├── firstboot
│   └── ublue-firstboot.desktop
└── just-config
    └── justfile
└── update-services
    └── etc
        └── rpm-ostreed.conf

We may also want to specify that the sub-project folders shouldn't contain the name ublueublue since it sounds a bit too repetitive and long-winded?

Compare /usr/share/ublue-os/ublue-os-update-services/usr/share/ublue-os/ublue-os-update-services vs the cleaner /usr/share/ublue-os/update-services/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><tab>-completion in the shell.

Anyway... this was just meant to start the discussions. Looking forward to hearing your ideas.

fiftydinar•5/10/23, 5:32 AM

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?

Ffiftydinar How would the changes be handled from let's say, Fedora 37 to 38 or Fedora 36 to...

ArcitecOP•5/10/23, 6:41 AM

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.

AArcitec These files are bundled inside the image at the system level, so you'll always a...

fiftydinar•5/10/23, 8:20 AM

So far from what I read, your suggestion is good. Have nothing in my mind to improve.

But I'm noob, so eh.

ArcitecOP•5/10/23, 2:22 PM

@j0rge I just spotted something:

https://github.com/ublue-os/main/blob/main/post-install.sh

cp /usr/share/ublue-os/ublue-os-update-services/etc/rpm-ostreed.conf /etc/rpm-ostreed.conf

cp /usr/share/ublue-os/ublue-os-update-services/etc/rpm-ostreed.conf /etc/rpm-ostreed.conf

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:

cp /usr/share/ublue-os/update-services/etc/rpm-ostreed.conf /etc/rpm-ostreed.conf

cp /usr/share/ublue-os/update-services/etc/rpm-ostreed.conf /etc/rpm-ostreed.conf

j0rge•5/10/23, 2:23 PM

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

j0rge•5/10/23, 2:23 PM

we strongly prefer design discussions in github and not here

Jj0rge we strongly prefer design discussions in github and not here

ArcitecOP•5/10/23, 2:27 PM

I have a proposal above:

System-wide uBlue Location

Which issue tracker do you want it at? /main?

j0rge•5/10/23, 2:28 PM

stick it in the forum and add the "proposal" label

j0rge•5/10/23, 2:28 PM

https://github.com/orgs/ublue-os/discussions?discussions_q=is%3Aopen+label%3Aproposal

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.

j0rge•5/10/23, 2:28 PM

then just edit it as people leave comments

ArcitecOP•5/10/23, 2:28 PM

Nice, will do

j0rge•5/10/23, 2:28 PM

I've got some calls today but will check it out this afternoon!

j0rge•5/10/23, 2:29 PM

@bsherman about to get on a call with a podman person, seeing if we can get that examples repo going

Jj0rge I've got some calls today but will check it out this afternoon!

ArcitecOP•5/10/23, 2:36 PM

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

Jj0rge @bsherman about to get on a call with a podman person, seeing if we can get that...

ArcitecOP•5/10/23, 2:36 PM

Sweet, good luck!

AArcitec No problem. There's no hurry on this. Everything can be moved smoothly when it's...

fiftydinar•5/10/23, 2:37 PM

This bug is probably a reason why I could not get gnome-vrr update, so I had to do full reinstall of it

fiftydinar•5/10/23, 2:37 PM

I changed the name of the repo iirc from initial one

fiftydinar•5/10/23, 2:38 PM

I thought back than that f37 in the name would make problems, so I changed it to generic one

Ffiftydinar This bug is probably a reason why I could not get gnome-vrr update, so I had to ...

ArcitecOP•5/10/23, 2:38 PM

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...

fiftydinar•5/10/23, 2:39 PM

Alright, I will

ArcitecOP•5/10/23, 2:39 PM

Thanks, it helps.

AArcitec Thanks, it helps. 🙂 ❤️

fiftydinar•5/10/23, 2:51 PM

Done

Ffiftydinar Done

ArcitecOP•5/10/23, 2:53 PM

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.

j0rge•5/10/23, 2:58 PM

I don't think the repo name was the issue with that one

fiftydinar•5/10/23, 3:02 PM

Changing the repo file name & repo content itself is indeed different

Jj0rge I don't think the repo name was the issue with that one

ArcitecOP•5/10/23, 3:04 PM

Indeed but I didn't feel like pointing it out. It's still a fine, semi-related comment, hehe.

ArcitecOP•5/10/23, 3:06 PM

Either way, cgwalters tagged the ticket as triagedtriaged 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

System-wide uBlue Location

Similar Threads

Similar Threads

Similar Threads