Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Switch from pkgctl-build to mkarchroot for chroot for better compability #905

Open
RubenKelevra opened this issue Aug 10, 2024 · 4 comments
Labels
request A feature request from a user.

Comments

@RubenKelevra
Copy link
Contributor

I've looked at your current implementation of the chroot, and I'm not really sure why you've chosen pkgctl-build over mkarchroot.

From my understanding, pkgctl-build has several disadvantages:

  • it can't use the makepkg.conf of the system
  • it can't use the pacman.conf of the system
  • it can't use the package cache of pacman
  • it doesn't support copying files into the chroot

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 yuis 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 just pacman -Su or pacman -S $dependency.

@fosskers
Copy link
Owner

fosskers commented Aug 11, 2024

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.

@fosskers fosskers added the request A feature request from a user. label Aug 11, 2024
@ultimatespirit
Copy link

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...)

@RubenKelevra
Copy link
Contributor Author

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 :/

@RubenKelevra
Copy link
Contributor Author

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...)

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
request A feature request from a user.
Projects
None yet
Development

No branches or pull requests

3 participants