Open RubenKelevra opened 3 months ago
it doesn't support copying files into the chroot
Files, or packages? Packages it can do via -I
.
because of missing repositories, which are not specified in the standard pacman.conf (like dependent on multilib or custom repositories).
That's definitely an issue. Is it possible that I'm just not using pkgctl-build
well enough? I'll look at it's options again.
why you've chosen pkgctl-build over mkarchroot.
Because pkgctl-build
is a first-class package and was suggested to me in this feature request.
why you've chosen pkgctl-build over mkarchroot.
Because
pkgctl-build
is a first-class package and was suggested to me in this feature request.
And to chime in, the reason for that is... I didn't even know mkarchroot
existed haha. pkgctl-build
was suggested on the arch-wiki for what I was seeking, doing a full clean build of a package, and I sort of just got around the cache issues / repository issues by boostrapping every single one of my pkgctl-build
invocations with additional packages for it to install (i.e. if AUR package foo
depended upon AUR package bar
I'd run the build for bar
and then for foo
with a dependency on the created bar
package...)
it doesn't support copying files into the chroot
Files, or packages? Packages it can do via
-I
.
Files like the pacman.conf or the makepkg.conf and package archive files, so dependencies doesn't need to be downloaded twice, as they are already in the system cache.
because of missing repositories, which are not specified in the standard pacman.conf (like dependent on multilib or custom repositories).
That's definitely an issue. Is it possible that I'm just not using
pkgctl-build
well enough? I'll look at it's options again.
Well, I've studied the man page 3 times, it just doesn't have the features we need.
It's more for a package maintainer who just wants to build a single package to test if it builds cleanly.
But as soon as we're not talking about vanilla arch with standard config, we're running into issues with this command.
why you've chosen pkgctl-build over mkarchroot.
Because
pkgctl-build
is a first-class package and was suggested to me in this feature request.
Ah okay. Yeah I think we have to switch :/
why you've chosen pkgctl-build over mkarchroot.
Because
pkgctl-build
is a first-class package and was suggested to me in this feature request.And to chime in, the reason for that is... I didn't even know
mkarchroot
existed haha.pkgctl-build
was suggested on the arch-wiki for what I was seeking, doing a full clean build of a package, and I sort of just got around the cache issues / repository issues by boostrapping every single one of mypkgctl-build
invocations with additional packages for it to install (i.e. if AUR packagefoo
depended upon AUR packagebar
I'd run the build forbar
and then forfoo
with a dependency on the createdbar
package...)
Yeah, but this doesn't work in all cases.
Dependencies in repos which are not in the standard repos won't work.
This means in case of Cachy OS for example that the build will be done with different package versions than the system libraries, as the default package versions are not optimized and they are optimized on installation, so the pacman.conf
is always different than what's in the pacman
package.
This may work, but if the build process includes the libraries, it will use the not optimized versions.
As the makepkg.conf
is not copied it will also result in different build settings than configured in the system, which is kinda unexpected.
So build would be slow, as its single thread and also without any flags which the user may have configured for his system, resulting in less security features or less performance settings etc.
I've looked at your current implementation of the chroot, and I'm not really sure why you've chosen
pkgctl-build
overmkarchroot
.From my understanding,
pkgctl-build
has several disadvantages:This leads to packages which are not build as specified in the user's makepkg.conf and packages not being build at all, because of missing repositories, which are not specified in the standard pacman.conf (like dependent on multilib or custom repositories).
It also means all dependencies needs always be fetched from the internet, instead of being fetched from the package cache of pacman, creating unnecessary traffic and slowing down the build process.
Via the copying function of files into the chroot, the package databases can also be copied into the chroot. While this may sound counterintuitive at first, it ensures that a package is build with the same libraries available on the host system - since the host just updated them, before the build process (installing packages without
yu
is considered unsafe).Meaning if you build say 10 packages over several hours the library versions cannot diverge between the host and the chroot, because inside the chroot you wouldn't run a
pacman -Syu
and instead justpacman -Su
orpacman -S $dependency
.