can you use xut in one system have the workarea and install in a chroot? #54

joborun2 commented 2025年12月01日 01:18:19 +01:00

xut -r /mnt

this may help with someone wanting to compile in other arch. or musl/glibc and v/v

Maybe build from 0 chroot everything from scratch, like xut bootstrap

In reference to the void system check it will have to apply to the chroot. What I am not so sure of is how hard would this be for running in chroot as user when system doesn't exist fully, since proper chroot usually requires root to do it ..

Just a thought of expanding the scope of xut

xut -r /mnt this may help with someone wanting to compile in other arch. or musl/glibc and v/v Maybe build from 0 chroot everything from scratch, like xut bootstrap In reference to the void system check it will have to apply to the chroot. What I am not so sure of is how hard would this be for running in chroot as user when system doesn't exist fully, since proper chroot usually requires root to do it .. Just a thought of expanding the scope of xut

mobinmob commented 2025年12月01日 07:07:48 +01:00

I am not sure if this will fit in the same utility.
I would rather have small utilities that reuse the xut structure on the fs, the configuration file and even the functions.
Your proposal can be the base for xut-install :P
I am assigning that to myself for a future release, thanks :)

I am not sure if this will fit in the same utility. I would rather have small utilities that reuse the xut structure on the fs, the configuration file and even the functions. Your proposal can be the base for xut-install :P I am assigning that to myself for a future release, thanks :)

joborun2 commented 2025年12月01日 23:08:41 +01:00

I was thinking that since it already makes the use of xbps to install packages build the only difference would be an -r /$target

Whether the work area is inside the target/chroot or not it makes no difference, I think. Of course this is not totally thought through yet. For xbps to be able to install the target must already be setup (doas root mkdir -p $target/var/db/xbps ) then it can install the 1st pkg (this means a simple if check if true function before first attempt).

Then one at a time pkgs built can be installed. I guess building and storing them in a local repository without installing them in the root system( and running the proper xbps function to install them afterwards is the same.

xut -b -i base-minimal -r /mnt
would be nice

Also, maybe a bit off topic, I assume xut sets arch/libC native to the host system, I don't see how you can set those in xut to be different like build on x64 glibc arm7/musl

I was thinking that since it already makes the use of xbps to install packages build the only difference would be an -r /$target Whether the work area is inside the target/chroot or not it makes no difference, I think. Of course this is not totally thought through yet. For xbps to be able to install the target must already be setup (doas root mkdir -p $target/var/db/xbps ) then it can install the 1st pkg (this means a simple if check if true function before first attempt). Then one at a time pkgs built can be installed. I guess building and storing them in a local repository without installing them in the root system( and running the proper xbps function to install them afterwards is the same. xut -b -i base-minimal -r /mnt would be nice Also, maybe a bit off topic, I assume xut sets arch/libC native to the host system, I don't see how you can set those in xut to be different like build on x64 glibc arm7/musl

mobinmob commented 2025年12月02日 08:50:59 +01:00

@joborun2 wrote in #54 (comment):

I was thinking that since it already makes the use of xbps to install packages build the only difference would be an -r /$target

The main change, i.e. the code that will do the installation to a directory is just an xbps-install invocation.
But I cannot add just that. I need to:

• check if the dir is writable and provide a proper message,
• wire the new argument to the getopts loop and make sure it does not conflict with anything else,
• update my already existing functions to take the new option into account,
• provide a way for the user to add other, non-local repositories,
• etc...

It is not difficult per se, but it adds code to an already growing script (written in posix sh without local at least...).
What you are proposing is very desirable functionality, but it does not belong in the same script IMHO.

Whether the work area is inside the target/chroot or not it makes no difference, I think. Of course this is not totally thought through yet. For xbps to be able to install the target must already be setup (doas root mkdir -p $target/var/db/xbps ) then it can install the 1st pkg (this means a simple if check if true function before first attempt).

OK, you just added a level of complexity just by using doas (which the user should have configured properly). Now I have to test for this and/or document the new dependency. That is what I mean...
I agree with the end result, but I want the complexity to be managed for the script to be maintainable.

Then one at a time pkgs built can be installed. I guess building and storing them in a local repository without installing them in the root system( and running the proper xbps function to install them afterwards is the same.

xut -b -i base-minimal -r /mnt would be nice

xut-bootstrap -r /mnt -p base-minimal may be even nicer :P
I can always add a command multiplexer like vpm that will invoke the proper utility later.

Also, maybe a bit off topic, I assume xut sets arch/libC native to the host system, I don't see how you can set those in xut to be different like build on x64 glibc arm7/musl

xbps-src does that automatically (setting the arch and libc). You can instruct xbps-src to create a masterdir for a different arch-libc combination and then it can cross-compile for this target.
This is not in the xut (the script, not the project) scope.
I would really like to expand what the project does and your proposals are helping. But I need to have certain things in place first - a main thing is automatic testing, @zenobit and @AngMits are doing excellent work on this. I also need to cleanup and optimise xut. An optimisation in discover_updates() I am testing locally cut the time needed to calculate updates to 1/10...

@joborun2 wrote in https://codeberg.org/mobinmob/xut/issues/54#issuecomment-8636883: > I was thinking that since it already makes the use of xbps to install packages build the only difference would be an -r /$target The main change, i.e. the code that will do the installation to a directory is just an xbps-install invocation. But I cannot add just that. I need to: - check if the dir is writable and provide a proper message, - wire the new argument to the getopts loop and make sure it does not conflict with anything else, - update my already existing functions to take the new option into account, - provide a way for the user to add other, non-local repositories, - etc... It is not difficult per se, but it adds code to an already growing script (written in posix sh without local at least...). What you are proposing is **very** desirable functionality, but it does not belong in the same script IMHO. > Whether the work area is inside the target/chroot or not it makes no difference, I think. Of course this is not totally thought through yet. For xbps to be able to install the target must already be setup (doas root mkdir -p $target/var/db/xbps ) then it can install the 1st pkg (this means a simple if check if true function before first attempt). OK, you just added a level of complexity just by using doas (which the user should have configured properly). Now I have to test for this and/or document the new dependency. That is what I mean... I agree with the end result, but I want the complexity to be managed for the script to be maintainable. > Then one at a time pkgs built can be installed. I guess building and storing them in a local repository without installing them in the root system( and running the proper xbps function to install them afterwards is the same. > > xut -b -i base-minimal -r /mnt would be nice `xut-bootstrap -r /mnt -p base-minimal` may be even nicer :P I can always add a command multiplexer like vpm that will invoke the proper utility later. > Also, maybe a bit off topic, I assume xut sets arch/libC native to the host system, I don't see how you can set those in xut to be different like build on x64 glibc arm7/musl `xbps-src` does that automatically (setting the arch and libc). You can instruct xbps-src to create a masterdir for a different arch-libc combination and then it can cross-compile for this target. This is not in the xut (the script, not the project) scope. I would really like to expand what the project does and your proposals are helping. But I need to have certain things in place first - a main thing is automatic testing, @zenobit and @AngMits are doing excellent work on this. I also need to cleanup and optimise xut. An optimisation in `discover_updates()` I am testing locally cut the time needed to calculate updates to 1/10...

joborun2 commented 2025年12月03日 00:04:33 +01:00

I may be wrong and not on the system from where I can check now, but somehow a user (not root) using xut is able to install a package into the system, therefore rights elevation. I think it is done through an xtools script, which utilizes doas, if I am not mistaken. So indirectly doas is already installed as a dependency of xtools.

I may be wrong and not on the system from where I can check now, but somehow a user (not root) using xut is able to install a package into the system, therefore rights elevation. I think it is done through an xtools script, which utilizes doas, if I am not mistaken. So indirectly doas is already installed as a dependency of xtools.

mobinmob commented 2025年12月03日 06:59:36 +01:00

xut uses xi for installation, which in turn uses sudo. That is needed only for installation/upgrade and I have documented it.
My point is that even something that seems small (just an invocation of xbps-install) can result in more complexity added, which the shell is not really suited for. I want the functionality, but I am not sure I can maintain everything in a single script.
xut was originally naively structured and it shows - template list creation is all over the place for example.
I have done work to improve it on this front, see #52 .
In order to add funtionality, I need a robust base. It is getting there :)
I want to to a big restructuring, but it will be post-release (after 0.4.1 that is). It will likely incorporate ideas from #40 by @zenobit.

`xut` uses `xi` for installation, which in turn uses `sudo`. That is needed only for installation/upgrade and I have documented it. My point is that even something that seems small (just an invocation of xbps-install) can result in more complexity added, which the shell is not really suited for. I want the functionality, but I am not sure I can maintain everything in a single script. `xut` was originally naively structured and it shows - template list creation is all over the place for example. I have done work to improve it on this front, see https://codeberg.org/mobinmob/xut/pulls/52 . In order to add funtionality, I need a robust base. It is getting there :) I want to to a big restructuring, but it will be post-release (after 0.4.1 that is). It will likely incorporate ideas from https://codeberg.org/mobinmob/xut/pulls/40 by @zenobit.