You can actually do makechrootpkg -I <pkg> and it will handle the required package installation
Yes, this is specified in the --help text for makechrootpkg. Did anyone say you couldn't?
]]>Since makechrootpkg is designed to do builds from scratch, it will definitely take some non-zero time to install all dependencies in a transitory container, on top of the persistent base container which only has base-devel installed. It's definitely the way to go to avoid polluting the build environment though.
You can actually do makechrootpkg -I <pkg> and it will handle the required package installation
]]>@Eschwartz
AFAIK makepkg -sr requires root privileges - whether in a chroot environment or not - to install and uninstall the deps.
I would like to avoid giving my build user account any root privileges.
What I'm trying to avoid is basically both, installing and uninstalling the packages and polluting my build environment.
I am using a build server with a binary repo as mentioned above. A link to the repo is currently (2018-09-18) in my signature.
I never heard of makechrootpkg. But it sounds interesting as well as promising and I will definitely have a look at it this evening.Thanks again.
makechrootpkg would *replace* your build user, and obviously it needs root in order to use systemd-nspawn. But packages are built in a container so the build user should not accidentally mess up the system with root privileges, and even the container builduser only has sudo privileges to run pacman itself (for makepkg -s)
Since makechrootpkg is designed to do builds from scratch, it will definitely take some non-zero time to install all dependencies in a transitory container, on top of the persistent base container which only has base-devel installed. It's definitely the way to go to avoid polluting the build environment though.
]]>@Slithery
Currently I am building packages for my private repo on my homeserver directly with a certain "build" user.
But you are right, a separate chroot or even a VM would be preferable. I think I'll migrate to the former.
@edacval
I did not test this but it sounds like it could work.
But since I am hosting the respective PKGBUILDs in the AUR I do not want to confuse other possible users with an unexpected PKGBUILD structure and also force them to "skip" the running dependency checks.
@Trilby
Maybe I was too cautious. You're probably right in suggesting that I just use makepkg -d, since I actually know what I'm doing.
@Eschwartz
AFAIK makepkg -sr requires root privileges - whether in a chroot environment or not - to install and uninstall the deps.
I would like to avoid giving my build user account any root privileges.
What I'm trying to avoid is basically both, installing and uninstalling the packages and polluting my build environment.
I am using a build server with a binary repo as mentioned above. A link to the repo is currently (2018-09-18) in my signature.
I never heard of makechrootpkg. But it sounds interesting as well as promising and I will definitely have a look at it this evening.
Thanks again.
]]>It really depends on what you're trying to avoid. Is it the time taken to install then uninstall? Is it the fact that packages get left over?
Are you using a build server that hosts a binary repo? Maybe it would be a good idea to use makechrootpkg, which also saves you from automagic dependencies as well as fully isolating the build, and is generally speaking a really nifty idea that more people should take advantage of.
2) Use makepkg -d which is discouraged by the man page.
What do you mean it is discouraged? Where, how?
The man page says it may break things if the dependencies are needed for building the package, but you are claiming that you already know this not to be the case.
]]>