Replies: 6 comments 25 replies
-
|
I think most of this adjusting |
Beta Was this translation helpful? Give feedback.
-
Yeah, let's do everything that we add to the system that doesn't have a standardized location already. Edit: Added "What to do when the files are intended for another, upstream project" section to proposal regarding this. |
Beta Was this translation helpful? Give feedback.
-
|
Good idea, I was looking for smth like this in the unix/linux/xdg standard when thinking of moving Collecting different paths/files I think should be in the directory.Edit: I had previously left out
|
Beta Was this translation helpful? Give feedback.
-
|
@EinoHR Interesting... I had that thought originally, and then tacked on But you're making me tempted to lean back towards just using the upstream name directy... What are your thoughts after hearing why I added |
Beta Was this translation helpful? Give feedback.
-
|
Oh and the |
Beta Was this translation helpful? Give feedback.
-
Well, I still don't think it's necessary. After all, after seeing the contents of the directory it should at the very least be obvious that it is a config folder, and since many of the other folders also include configs it should be alright. Differentiating between us and upstream in folder names is not something I find useful, either. It's not a just config, it's a just justfile. It contains little shell script snippets, not configuration for the just program. It's interesting to hear the |
Beta Was this translation helpful? Give feedback.
-
|
@EinoHR You've convinced me that it's still clear enough that it's "only the config, not the whole just project", so let's use Regarding bin for any custom binaries, that's a great idea. I'll add it to the top post. |
Beta Was this translation helpful? Give feedback.
-
|
The top post has been thoroughly revised to incorporate everything from this thread. I'll address the |
Beta Was this translation helpful? Give feedback.
-
|
@EinoHR Another issue: I discovered that I propose that we also move the yafti config for startingpoint where it belongs, to |
Beta Was this translation helpful? Give feedback.
-
|
I agree with that. |
Beta Was this translation helpful? Give feedback.
-
|
@EinoHR Pull request is ready, since there haven't been any interjections so far. Everyone seems to go "yep, that's a nice location", so let's just do it and not bikeshed too much more. It's a great location. Here's the first pull request. |
Beta Was this translation helpful? Give feedback.
-
|
@Arcitec Let's talk I think it's a bit messy right now (I've contributed to that), but not sure how to improve, or if it needs it. State of things:
So, when I say messy, I mean it's a bit awkward to be directly appending to an RPM managed file... however, I think I like that better than not having it managed at all. There IS this issue over here ublue-os/config#16 which i think could help us... once Given the proposed solution I linked, not sure there's much to change at the moment with |
Beta Was this translation helpful? Give feedback.
-
I think startingpoint should be using the |
Beta Was this translation helpful? Give feedback.
-
Thanks for confirming. I am inclined to fix our paths ( for |
Beta Was this translation helpful? Give feedback.
-
|
@bsherman @EinoHR After some discussion on Discord, a good pattern emerged to avoid forks overwriting each other's justfiles randomly: Every image instead has its own separate justfile, which the user can include/merge a-la-carte. Currently we have these: touch ~/.justfile
cat /usr/share/ublue-os/just/main.just >> ~/.justfile
cat /usr/share/ublue-os/just/custom.just >> ~/.justfileThe The We'll need 4 minor changes in how the main justfile is built:
Alright here's the fixed # Add uBlue's justfiles to user if they don't already have a justfile.
if [ ! -f "${HOME}/.justfile" ] && [ -f /usr/share/ublue-os/just/main.just ]; then
cp /usr/share/ublue-os/just/main.just "${HOME}/.justfile"
fiIn time I will probably contribute to the other repos too, but at the moment I am still busy and uncomfortable with the structure of main, config and nvidia. I'm starting to study them though! :) |
Beta Was this translation helpful? Give feedback.
-
|
I referenced this latest comment as a new issue: ublue-os/config#41 |
Beta Was this translation helpful? Give feedback.
-
|
FYI for all config's udev-rules and update-services should be compliant with this proposal: |
Beta Was this translation helpful? Give feedback.
-
|
Absolutely fantastic work. <3 |
Beta Was this translation helpful? Give feedback.
-
|
With the merge of ublue-os/config#42 I'd say this discussion has been fully actioned. |
Beta Was this translation helpful? Give feedback.
-
We currently have a bit of a mess, with components placing their files wherever they want. There's a need for a standardized location where all ublue components can safely and cleanly dump their necessary files.
Some examples of our component data would be things like immutable config files, templates, artwork/images, and potentially even binaries (for any components that shouldn't pollute places like
/usr/bin/). We need to unify it all in one location.Need for immutability
The location we choose must be immutable, to avoid issues during OS upgrades (for example, user-modified files or configs in
/varor/etcwould not be upgraded).As such,
/usr/share/ublue-oswould be a great location, and there's already precedent for using it.Need for sub-project namespaces
To avoid components stepping on each other, especially if they contain many files (or if they grow to multiple files in the future), we should definitely have sub-project folders. That way everyone can work on component projects without worrying about overwriting other component files by accident.
Avoiding repetition
Many of our components have "ublue" in the official name, which gives us very clunky paths. I think that we should avoid that in the sub-project folders.
Proposal
Here's an idea for a structure:
So for our current needs, with the "update service", the startingpoint's "first boot" files (desktop-file and yafti config), our global "just" config, and the startingpoint recipe, it would look like this:
Important: You may notice that recipe.yml isn't in a folder. This is just a suggestion, since it's the "overall recipe" used for the whole OS, so it doesn't really need a sub-folder, and since it's something that people may want to look at, it sits really neatly in
/usr/share/ublue-os/recipe.ymlin my opinion. What are your thoughts on that exception?Regarding "loose" config files and upstream configs that lack standardization: We should have one sub-directory for each upstream project, such as
/just/in the example above. I thought about having a specific sub-directory where we combine all loose configs, but after more consideration, let's not do/usr/share/ublue-os/configs/custom.just, since that re-introduces the old issue we had where components could accidentally overwrite each other's files. And certain components can contain a lot of small config files, which would quickly make a universal "configs" sub-directory very messy. Upstream projects can also grow over time, requiring more and more little files, which should all live in separate per-upstream folders to be safer. So let's instead do something like the proposed/<upstream project>/sub-directories, such as/usr/share/ublue-os/just/*in this example. I can also easily imagine that ublue and downstream images will be adding a lot of configs over time, so we definitely need to sort this out and serve as a good example for the rest of the ublue community. Putting anything directly in/ublue-os/rather than a sub-folder would be a very bad example to the downstream OCI images and would encourage bad habits.Why not a
/usr/share/ublue-os/configs/directory?: It was discussed, but having a/configs/directory instead of specific per-project folders such as/just/could confuse ublue contributors and downstream users over time and make new contributors start to use that directory for our own configs (our own components), which shouldn't be the purpose. So let's not do that... Because if there's a/usr/share/ublue-os/configs/directory, we could start getting the feeling that "that's where all ublue configs go". It creates the opposite "that doesn't feel right", where we'll have a bunch of native ublue components that don't use that directory, and a bunch of loose upstream components that use it. It'll be very confusing. That's why it makes more sense to separate/<upstream project name>/folders for each individual upstream project config.Examples of avoiding name-repetition
Compare the clarity and readability of the following paths:
/usr/share/ublue-os/ublue-os-update-services/usr/share/ublue-os/update-servicesIt'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.Therefore, it makes sense to enforce a strict "don't repeat yourself" policy for the sub-folders.
What to do with justfiles
It was discovered that various uBlue projects were overwriting each other's justfiles. For that reason, it was decided that each justfile should have its own prefix. At the moment, we have the following justfiles:
The "main" file comes from
ublue-os/mainand the "custom" file is from theublue-os/startingpointtemplate. Other projects and downstream images should follow the same pattern for their own justfiles.Note that all justfiles must end in
.just, which is the official "upstream" naming pattern. Just officially uses the<something>.justsuffix for all include-files:https://just.systems/man/en/chapter_52.html
What to do when the files are intended for another, upstream project
/usr/share/ublue-os/<project name>/hierarchy. Thejustfiletemplate is included in the example hierarchy diagram above, for that reason, since they don't have any upstream storage location. (Furthermore, "just" is working on being able to use "include" statements, and then it'll be nice to simply be able to~/.justfile: include /usr/share/ublue-os/just/custom.justfor users who want our config.That way we'll have a super clean, reliable, maintainable and non-confusing system.
Let's discuss!
Looking forward to hearing your thoughts and ideas!
Beta Was this translation helpful? Give feedback.
All reactions