You are not logged in.
I know from the official PKGBUILD docs, that depends is implicitely included in makedepends.
While I understand that this makes sense, especially for compiled programs, it is an unnecessary hassle for me, when I create python packages.
They often have runtime / usage dependencies when installed as a package for actually being used, but which are not required to actually build the package.
This forces me to either
1) Install all dependencies for each package to be built on the build system or
2) Use makepkg -d which is discouraged by the man page.
So in order to have my cake and eat it, i.e. have my dependecies checked but skip those which are not required for just building the package, is there maybe a "hidden" option for that, which I overlooked?
Or am I actually forced to either install packages not needed for the build or entirely skip my dependency checks?
Last edited by schard (2018-11-13 14:11:32)
macro_rules! yolo { { $($tokens:tt)* } => { unsafe { $($tokens)* } }; }
Online
What about building all of your packages in a clean chroot like all of the devs (and a few of the rest of us), that way you don't have to "pollute" your system with unnecessary packages.
Offline
Just move depends=() into package() function
Offline
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.
"UNIX is simple and coherent..." - Dennis Ritchie, "GNU's Not UNIX" - Richard Stallman
Offline
An alternative to makepkg -d would be makepkg -sr, which installs them to build, then removes them.
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.
Managing AUR repos The Right Way -- aurpublish (now a standalone tool)
Offline
Hi all and thank you for your replies.
@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.
Last edited by schard (2018-09-18 07:53:49)
macro_rules! yolo { { $($tokens:tt)* } => { unsafe { $($tokens)* } }; }
Online
@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.
Managing AUR repos The Right Way -- aurpublish (now a standalone tool)
Offline
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
Offline
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?
Managing AUR repos The Right Way -- aurpublish (now a standalone tool)
Offline