FS#45882 - [devtools] No support for local repositories
Attached to Project:
Arch Linux
Opened by James Harvey (jamespharvey20) - Monday, 03 August 2015, 22:18 GMT
Last edited by Eli Schwartz (eschwartz) - Wednesday, 21 August 2019, 04:50 GMT
Opened by James Harvey (jamespharvey20) - Monday, 03 August 2015, 22:18 GMT
Last edited by Eli Schwartz (eschwartz) - Wednesday, 21 August 2019, 04:50 GMT
|
Details
If .pkg.tar.xz files are in a top-level system local
repository, but are not in the top-level's pacman cache
directory (have never been installed outside of the
chroots), devtools doesn't support local repositories.
I use devtools to build AUR packages, for myself. (I love having a minimal install, minimal explicitly installed packages, and not having makedepends packages installed globally.) In my top-level system, my /etc/pacman.conf has a local repo with "Server = file:///<mountpoint>". I copied /usr/share/devtools/{makepkg-x86_64.conf,pacman-extra.conf} to /etc/{devtools-makepkg-x86_64.conf,devtools-pacman.conf}, and extra-x86_64-build to devtools-x86_64-build. Modified devtools-x86_64-build to call setarch and arch-nspawn with the -C and -M options pointing to the /etc files. The /etc files are changed to include the local repository, and to use -j12 for MAKEFLAGS. As it is now, arch-nspawn invokes /chrootbuild, which knows to look at the file:/// location for the local repository. (arch-nspawn copied my /etc/devtools-pacman.conf to inside the chroot /etc/pacman.conf.) But, in the arch-nspawn/chroot, that local repository is not actually mounted, so is inaccessible. If arch-nspawn around lines 293-300 were to look for local repositories, and bind mount them, I think that's the only change that would be needed to add local repository support to devtools. Short of that, before I understood what was going on, I had realized that if I installed and removed an AUR package from my local repo into my global system, and eventually realized if I just copied it into /var/cache/pacman/pkg, this is a workaround to get devtools to still use the packages I built. I sometimes forget to do this workaround, which causes the package to not be found, or a previous version to be used inside the chroot. arch-nspawn could parse its given -C file to look for the local repositories. Or, pacman could be invoked with --config and its given -C file, if pacman were modified to show local repositories perhaps through the -v option, which is used by arch-nspawn to find the mirrors used. |
This task depends upon
Closed by Eli Schwartz (eschwartz)
Wednesday, 21 August 2019, 04:50 GMT
Reason for closing: Fixed
Additional comments about closing: https://git.archlinux.org/devtools.git/c ommit/?id=69112171e5de910331e46cf3f84886 6550125024
Wednesday, 21 August 2019, 04:50 GMT
Reason for closing: Fixed
Additional comments about closing: https://git.archlinux.org/devtools.git/c ommit/?id=69112171e5de910331e46cf3f84886 6550125024
That being said, we could leverage pacconf from pacutils for this, see aurutils for an implementation that passes local repos to `makechrootpkg -d $localrepo`.
Do we want to add a pacutils dependency? I mean, I think everyone should have pacutils available, but that is hardly a good metric, especially as pacman itself is waiting for a self-hosted pacconf before fixing some longstanding bugs in shell completion parsing.