toolbox/distrobox rhel
that part i think needs some more thinking, are we talking about using the toolbox command instead or running the toolbox image inside distrobox like we do now?
53 Replies
here
https://github.com/ublue-os/config/issues/186 specifically came out of a PR to add rhel toolboxes
GitHub
provide option to use toolbox in our distrobox just recipes Ā· Issue...
I suggest maybe add an argument to all our distrobox recipes which allows toggling toolbox, and perhaps allows setting an env var which defaults to toolbox. The idea people that some users definite...
because if it is the latter, we can just supply a -toolbox.ini
the original ticket was not for adding rhel distroboxes but actually to add them with toolbox because ostensibly, "real RHEL people" are using toolbox, not distrobox
and toolbox can't do ini files
so, i approved a PR which did add rhel images to distrobox ... but with the caveat, and creation of ticket 186
hence i wanted to ask if we were talking about toolbox image or toolbox the binary
I had intended to implement a just arg for the distrobox images which could make them toobox instead... but then you @HikariKnight started your efforts so i wanted to get out of theway
yeah the red hatters use
toolbox the binary, they don't use distrobox at all. So the idea was "if you're using rhel then let's give it to them the way redhat wants it"</storytelling>
i will see if i can come up with something for toolbox, if i can make it use the ini files that would be awesome too, less maintenance work š
but there's also like zero reason to use toolbox for everyone else
if its just a check for the rhel/fedora image then thats easy
well should be easy
i imagined that either an environment variable or an arg to all the distrobox just recipes would flip between using distrobox or toolbox... but there's different args for each, too
but still, it would make us more friendly to people who may wish to use toolbox not distrobox
ujust toolbox- here we comebut once you started working, i wasn't really sure how it would look.
just wanting to make sure the context is clear here
yeah I'm not sure it's worth the added complexity to have people switch to a tool we specifically moved away from, but don't have strong opinions as long as it's well scoped and distrobox is the default
like, if people ask which should I use we tell them distrobox but having a choice implies that using toolbox is fine
toolbox IS fine
š
if args can be relatively translated, it can be added to the distrobox tooling (at least the
Distrobox function)
if it cant then its a separate just recipei do think your changes got rid of all the
distrobox-FOO recipes and replaced with a single distrobox which takes an arg/choice, right?
if that's the case, then having toolbox in addition to distrobox may be fine
but i do see what Jorge is saying... having both implies they can both be used
and they can... but it's confusingyeah i got rid of all the distrobox-foo commands
right and then we'll have people saying "I can't use this properly" because they're following fedora's recommendations
i wish we'd started with "toolbox-foo" but used distrobox as the implementation... since even distrobox uses the "toolbox" container tag
"how come I use ublue and I can't create seperate home directories for my toolboxes?"
(I'm playing devil's advocate)
but our just recipe doesn't create separate home dirs
no what I'm saying is we use distrobox instead of toolbox
and i don't think it should... should be a simple set of defaults
but we don't remove toolbox
new one has an arg for it but only if you pass it, it never asks if you do the "guided tour"
@HikariKnight : you've seen our respective thoughts š please crank out something awesome and we'll go from there š
we DO need another approver on the first PR though...
i think the easiest would be a
toolbox- recipe with its own tooling
but you cant use toolbox and distrobox at the same time for containers? if so i can write in a check for that
as i have 0 experience with toolbox, didnt exist last time i touched a centos boxwell, it existed before distrobox š
last time i touched a centos box i believe dnf didnt exist
i don't think it would be horrible... the "docstring" for
distrobox- could say "Create a toolbox container (using uBlue recommend distrobox)" and toolbox docstring could say "Alternative way to create toolbox containers"
or something"the RedHat way to create toolbox containers"
yeah, something like that
toolbox can use normal images or is it limited to just toolbox tailored images?
they both use the same images these days, I think
that was the original inspiration for distrobox, i think, ability to use "non-standard" images, but then toolbox added the same thing
a super dumb way to do the ini file to toolbox chain then could be to just look for each section/name and grab the value of the image key, if we can pass a full image path to toolbox š¤ splitting the release to its own string shouldnt be hard either as long as toolbox supports
latest as a release
but i can make the toolbox recipe just do rhel images first and see how it goes from there
i know i was joking about being stuck in config i didnt mean it literally ši mean, yeah, the core requirement here is for us to provide the set of rhel/fedora toolbox images via the toolbox tool, since that's what is expected by RedHatters and hard core RHEL/Fedora users...
but none of the other images NEED to be exposed that way
oh then this will be easier than i thought
and when i say fedora, i don't mean custom built fedora images from bluefin or anything like that, just bog standard upstream fedora-toolbox:39
or 38
etc
:latest
šeh, whatever the existing pattern is for the rhel stuff, i would have to look
but i can just give them a list then they can write version
gives me a reason to add
input to ugum i guess š
i will work on toolbox before i clean up bazzite just files and bluefin just files then, how that sound? after the distrobox PR is merged so bluefin and maybe bazzite can get to enjoy an "auto generated" image list for distroboxesif you think
toolbox- for rhel/fedora is a distinct recipe, then i wouldn't consider it blocking to your existing changeset
so i'd suggest making it another PRyeah if the image scope is way smaller than distrobox. It can be altered if the need ever arises. but from what i gathered here a separate recipe is what makes the most sense in my head right now
plus it would not give the false impression that they can yeet the homedir somewhere else
yeah glancing over the docs i would say having it as its own thing would be for the best, creates a clear separation too
I could ack the PR but I'm going to let an engineer do it.
(sorry got pulled into a meeting)
sounds reasonable, and it's a distinct PR from the distrobox improvements you already have in flight
just need to find one who is free š¤£ i dont know everyone in here well enough yet to know what everyone does.
but hi, if you have not figured yet. i do scripting and utilities and as my github says "i make things work" š¤£
@Kyle Gospo or @EyeCantCU will be the hero we need.
... to approve https://github.com/ublue-os/config/pull/194
If you need help with something, feel free to ping me at any point during the day
@bsherman @EyeCantCU
should be ready for checking now
https://github.com/ublue-os/config/pull/199
the distrobox part of the tooling