Maybe consider getting rid of some external dependencies #2039
Comments
|
I believe the HWE ones are gonna get removed at some point, arent they? - Otherwise honestly I think just stuff like the |
|
I believe a improvement would be a way to know which coprs are being used for which packages on the |
|
This has been on the todo for a while so might as well take care of it. The HWE ones go away, I'm fine with deps on the upstreams like k8s, tailscale, starship, etc. Bazitte uses Switcheroo and we work with sentry already, though it might make sense to move that one to ublue-os/packages since bazzite uses it. Hikari is on the ublue core team. The podman-bootc one is run by a redhat and fedora person, and likely has a path into Fedora anyway. The Incus stuff either gets better in-distro or we may choose to use timothee's sysexts for that. I feel like fonts should be a separate audit because that's a whole ball of stuff. I forgot what bash-preexec does, I think we use it with distrobox? |
FWIW I recognize bash-preexec as option for bash when using atuin. |
|
Bash pre exec is for atuin. |
|
Ah! Ok so we had atuin on the image itself at one point, but now it's an opt in install via homebrew, which should pull in everything it needs. So maybe we don't need this on the image anymore? |
|
Seems to be in use by As far as I can tell, brew provides a atuin binary, not your bash setup. |
|
At the very least, I would like to have more 'toggle-' options in ujust until the strategy for external dependencies have been worked through. I am currently coming to the conclusion that starship is a buggy and limiting mess. I am not sure what I am going to replace it with yet. But I would like to turn it off. For now I plan on just commenting out the line at the bottom of I would rather do That was just an example. In general, I would suggest something similar for the rest - within reason. |
Yeah, I did that and it seemed to work. My point is that until things can get to a point where all external dependencies are opt-in (as @tulilirockz points out in the original purpose of the request) - there are too many places to discover things like this. FAQ, other places in the docs or upstream docs and ujust. ujust has these:
What I am suggesting is pick one way of communicating optional system modifications and stick with it. So adding this seems like a good step forward:
That way if you need to modify how starship is integrated (perhaps by adding an opinionated default starship.toml file) then you could just modify the justfile and deal with it there. No need to document those changing details. The users of bluefin will thank you. And you will get less questions about these things. |
|
You don't need permission, send a pull request and we can take a look! |
|
I was just participating in the discussion. Seems this request is in an early design phase. I.e., what would the PR contain? My suggested ujust enhancement? Some docs adjustment (in the other repo)? Once an approach has been settled on, sure I would be willing to help. Development, docs, testing, whatever. The scope of the original request seems quite large. So I would be willing to help with any interim solution(s). I am loving bluefin! It is really causing me to challenge how I have been using my system. I am truly enjoying finding new techniques. For example, I use VS Code (devcontainers) and distrobox pets. But as I posted in the UB forum, they just do not play nice with each other. My current experiment has me building a set (actually hierarchy) of OCI images based on Then I use those common images for both distrobox and devcontainers. There is some complexity that I am working through. But there are some interesting benefits. For example, topgrade seems to update my running decontainers as well as distrob-oxen (pet pun intended). That is a cool side effect. It is early on, but the approach seems promising ... |
I don't want to be that security-focused weirdo person that thinks everything is a huuuuge booggie man and is gonna destroy the project, but I feel like as this project is getting more and more traction, we should consider reacessing which external dependencies are being added at least for the base Bluefin images (non -dx).
I'd consider an "external dependency" something that does not come from either the Fedora official repositories (rpm-fusion too), Homebrew packages, Flathub, or our own packages repository (or anything else on our org, like akmods, and others). Considering that, we currently have these external dependencies on base:
On HWE:
On DX we have these:
Other than these there are just things getting pulled from hwe and akmods, nothing really to worry about. But I'd just like to ask you guys if there would be anything that would be best to be moved to packages so that we could have more control over, or just straight up removed from the system
The text was updated successfully, but these errors were encountered: