[Solved-ish] What installation reason should be used for make-depends?

cfr · 2022-12-11 20:26:48

If I'm installing a package from AUR or using a homegrown PKGBUILD, I need to install any make-depends prior to building. Should these packages be installed as explicitly-installed or as dependencies?

If I install them explicitly and later remove the package which required them, pacman -Rs will not remove them and nor will they be listed as orphaned.

If I install them as dependencies, they will be included as orphaned and may be removed by pacman -Rs, even though they are needed for making needed packages. Of course, they are not needed by the running system, but only for building one or more packages, but they are not exactly not-needed either.

Is it best to list them as explicit ? Or is it best to list them as dependencies? Or is it best to uninstall them after building the package(s) which require them?

I seem to vacillate between the first two policies, neither of which is very satisfactory. I have not tried the third.

Last edited by cfr (2022-12-12 18:06:08)

Scimmia · 2022-12-11 20:42:23

Same as makepkg does, they get installed as dependencies. makepkg also has an option to clean up installed packages after the build.

If you're building in a clean chroot, which you should be, it's mostly moot, though.

cfr · 2022-12-11 21:24:07

Scimmia wrote:

Same as makepkg does, they get installed as dependencies. makepkg also has an option to clean up installed packages after the build.
If you're building in a clean chroot, which you should be, it's mostly moot, though.

I should?

Edit: I just followed the instructions at https://wiki.archlinux.org/title/Arch_User_Repository which don't say I should clone the git repository or makepkg in a chroot as far as I can see. They just say to do it as an ordinary user. (I actually do it as a different ordinary user who is not in wheel etc. and can't access my home directory.)

Last edited by cfr (2022-12-11 21:28:42)

Scimmia · 2022-12-11 21:48:04

https://wiki.archlinux.org/title/Develo … ean_chroot

Trilby · 2022-12-11 22:48:15

I just let makepkg install them (using the -s flag) and I remove them with my next cleanup of orphans (though using makepkg's -r flag would take care of this too, I just don't have a habit of that).

If there are certain build dependencies that you know you will regularly need and just want to keep them installed explicitly install that package. E.g., if you build a lot of rust programs, you may just want to keep rust installed. If there are few of these, you could make your own meta-package like cfr-devel which lists those build tools you commonly use that aren't in base-devel. This is precisely what base-devel is: a group of tools that is so commonly needed for building AUR packages that it is a group and most AUR users just keep base-devel installed.

cfr · 2022-12-11 23:09:54

Scimmia wrote:

https://wiki.archlinux.org/title/Develo … ean_chroot

Thanks, but I'm not a developer so I don't think this applies?

Trilby wrote:

I just let makepkg install them (using the -s flag) and I remove them with my next cleanup of orphans (though using makepkg's -r flag would take care of this too, I just don't have a habit of that).

I've never used -s because I don't want to run makepkg as a user with more privileges than necessary. (And some dependencies are AUR packages, though I admit many are not.)

However, it sounds as if I should probably be using --asdeps more often and maybe removing things more often.

Slithery · 2022-12-11 23:27:48

cfr wrote:

Thanks, but I'm not a developer so I don't think this applies?

Just because you aren't a dev doesn't mean that you can't use scripts such as extra-x86_64-buildfrom the devtools package.

Or you could just use graysky's clean-chroot-manager package to achieve the same thing.
All make depends are only installed into the build system chroot and never on to the machine that you are installing to.

Trilby · 2022-12-11 23:51:08

cfr wrote:

I've never used -s because I don't want to run makepkg as a user with more privileges than necessary.

Ah, this doesn't add up. You still run makepkg as a regular user. With the -s flag it just runs the same pacman command (with sudo / su) that you would to install the dependencies, it just handles gathering that list of target packages for you.

cfr · 2022-12-12 00:30:48

Trilby wrote:

Ah, this doesn't add up. You still run makepkg as a regular user. With the -s flag it just runs the same pacman command (with sudo / su) that you would to install the dependencies, it just handles gathering that list of target packages for you.

Yes, but I'd have to give the user sudo rights and I've been reluctant to do that. I dare say that's paranoid or pointless or both, but that's why I've never used -s.

slithery wrote:

Just because you aren't a dev doesn't mean that you can't use scripts such as extra-x86_64-build from the devtools package.

But is there a reason to? It means trying to knit together the AUR instructions with the developer instructions. That's a lot of complications if there's not a good reason to do it.

slithery wrote:

All make depends are only installed into the build system chroot and never on to the machine that you are installing to.

Is this a good reason to do it that way?

Right now, I rely on the previous PKGBUILD when an AUR package is updated. I imagine this would be lost (or, at least, be more complicated) if building in a chroot.

I'm not suggesting the way I do it right now is ideal. I'm just trying to get a sense of why people are suggesting the different things they're suggesting (since Trilby seems not to be using clean chroots?).

Trilby · 2022-12-12 00:40:15

cfr wrote:

Yes, but I'd have to give the user sudo rights and I've been reluctant to do that.

If your user doesn't have sudo rights, remove sudo, then makepkg -s will use `su`. But in any case, you need to run pacman somehow, right? That requires some way of elevating rights.

Slithery · 2022-12-12 00:47:18

cfr wrote:

slithery wrote:
Just because you aren't a dev doesn't mean that you can't use scripts such as extra-x86_64-build from the devtools package.
But is there a reason to? It means trying to knit together the AUR instructions with the developer instructions. That's a lot of complications if there's not a good reason to do it.

You don't have to 'knit together' anything. Just cd into the directory that contains the PKGBUILD and run extra-x86_64-build (or ccm c & ccm s) instead of makepkg.

cfr wrote:

slithery wrote:
All make depends are only installed into the build system chroot and never on to the machine that you are installing to.
Is this a good reason to do it that way?

Yes. It provides an answer to the question you asked about not having to install makedepends onto your system.

https://wiki.archlinux.org/title/Develo … ean_chroot
https://github.com/graysky2/clean-chroot-manager

Scimmia · 2022-12-12 01:00:32

All packages in the repos are built in a clean chroot for a reason. There are a LOT of projects that will autodetect things that are on your system, or not on your system, when building. A clean chroot gives you a clean way to build with exactly what the PKGBUILD specifies.

Awebb · 2022-12-12 05:07:07

Scimmia wrote:

https://wiki.archlinux.org/title/Develo … ean_chroot

The devtools method fails for me every time I try it. Example:

Installing auracle-git from the AUR

...
(1/1) Arming ConditionNeedsUpdate...
Checking PKGBUILD
PKGBUILD (auracle-git) W: PKGBUILD uses internal makepkg 'msg2' subroutine
Checking auracle-git-r366.8739929-5-x86_64.pkg.tar.zst
auracle-git W: Dependency included and not needed ('libcurl.so')
==> Running checkpkg
error: target not found: auracle-git
==> WARNING: Skipped checkpkg due to missing repo packages

Then it just dropps me in the shell again. It works with makepkg.

Scimmia · 2022-12-12 05:23:44

That's not a failure, after it builds it checks things with namcap and checkpkg. Everything worked just fine.

Awebb · 2022-12-12 05:33:00

Oh. The package is in my done folder, indeed. There isn't an -i flag, like for makepkg perchance?

Allan · 2022-12-12 05:58:21

I just use makepkg -i after running devtools.

cfr · 2022-12-12 07:16:00

I'm confused. Why does the wiki page on building AUR packages recommend a method which doesn't use a chroot if packages should always be built in a chroot?

If this is correct - and I'm certainly not suggesting it isn't - then why doesn't the AUR page explain how to do this for an AUR package? Of even that it should be done? I realise it may seem straightforward to people answering this, but ... I followed the wiki. When the AUR changed, I followed the wiki again. But I was following the wrong bit of the wiki?

Edit: Apologies. I spent the weekend trying to connect to a VPN so I can access files I used to access using cadaver. And I achieved nothing. I shouldn't have asked this question when I'm entangled in dead non-CIFS ends and addresses I can't figure out.

Last edited by cfr (2022-12-12 07:20:56)

Awebb · 2022-12-12 09:16:45

I think you might be getting a little too hung up on Scimmia's "which you should be". It's good advice, it's probably best practice in many cases, but it is not necessary to get a package built. The AUR page mentions clean chroots in the troubleshooting section. This is where you'll need a clean chroot to make sure you stay sane while trying to fix a PKGBUILD.

There is also the problem of wiki house keeping. The clean chroot article is in the dev namespace of the wiki and it's probably not entirely understandable for everyone. The tools have potentially confusing names. Unless that is somewhat cleaned up/streamlined, suggesting it to every single beginner might lead to exactly those support threads that suggesting a clean chroot tries to prevent in the first place.

Allan wrote:

I just use makepkg -i after running devtools.

Now I feel stupid.

Trilby · 2022-12-12 14:00:34

Awebb wrote:

I think you might be getting a little too hung up on Scimmia's "which you should be".

Ah, ShouldLand ...

FWIW I've never built an AUR package in a chroot. None of my computers have blown up... yet.

cfr · 2022-12-12 18:05:37

Awebb wrote:

I think you might be getting a little too hung up on Scimmia's "which you should be".

Trilby wrote:

FWIW I've never built an AUR package in a chroot. None of my computers have blown up... yet.

Ah, thanks to you both. I think I will keep it in mind for troubleshooting and not try to figure out a new workflow at the moment, at least. Trying to get my head around VPN is more than enough frustration for now!

tekstryder · 2022-12-13 00:04:14

Fun to see a thread where everyone is "right" haha!

Just to add another perspective...

For packages that don't require a ton of build-deps, or those that I build so frequently that I've kept those deps installed, I just makepkg in a certain folder and routinely (part of backup checklist) clean up orphans via pacman.

For one-off packages (testing upstream cherry-picks or commit reverts), or those that require a lengthy list of build-deps, I do the manual clean chroot build method. It's mighty easy - don't let that "dev" aspect sway you.

As the counter of times I've seen extra-x86_64-build mentioned in such discussions continues to increment I'll likely give that a go some near-future date!

sekret · 2022-12-13 13:01:32

I always build everything in a clean chroot and recommend this to everyone. But you certainly don't HAVE to do this!

Still, I'd give a +1 if Arch devs decide to make the chroot method the default.

cfr · 2022-12-13 15:40:43

sekret wrote:

Still, I'd give a +1 if Arch devs decide to make the chroot method the default.

Not quite sure what you mean by this. As I understand it, Arch packages are already built in a clean chroot. The Arch devs don't control whether people use the same method to build AUR/other packages for their own use or not. Or did you mean you'd like to see the wiki page recommend it as default?

Arch Linux

#1 2022-12-11 20:26:48

[Solved-ish] What installation reason should be used for make-depends?

#2 2022-12-11 20:42:23

Re: [Solved-ish] What installation reason should be used for make-depends?

#3 2022-12-11 21:24:07

Re: [Solved-ish] What installation reason should be used for make-depends?

#4 2022-12-11 21:48:04

Re: [Solved-ish] What installation reason should be used for make-depends?

#5 2022-12-11 22:48:15

Re: [Solved-ish] What installation reason should be used for make-depends?

#6 2022-12-11 23:09:54

Re: [Solved-ish] What installation reason should be used for make-depends?

#7 2022-12-11 23:27:48

Re: [Solved-ish] What installation reason should be used for make-depends?

#8 2022-12-11 23:51:08

Re: [Solved-ish] What installation reason should be used for make-depends?

#9 2022-12-12 00:30:48

Re: [Solved-ish] What installation reason should be used for make-depends?

#10 2022-12-12 00:40:15

Re: [Solved-ish] What installation reason should be used for make-depends?

#11 2022-12-12 00:47:18

Re: [Solved-ish] What installation reason should be used for make-depends?

#12 2022-12-12 01:00:32

Re: [Solved-ish] What installation reason should be used for make-depends?

#13 2022-12-12 05:07:07

Re: [Solved-ish] What installation reason should be used for make-depends?

#14 2022-12-12 05:23:44

Re: [Solved-ish] What installation reason should be used for make-depends?

#15 2022-12-12 05:33:00

Re: [Solved-ish] What installation reason should be used for make-depends?

#16 2022-12-12 05:58:21

Re: [Solved-ish] What installation reason should be used for make-depends?

#17 2022-12-12 07:16:00

Re: [Solved-ish] What installation reason should be used for make-depends?

#18 2022-12-12 09:16:45

Re: [Solved-ish] What installation reason should be used for make-depends?

#19 2022-12-12 14:00:34

Re: [Solved-ish] What installation reason should be used for make-depends?

#20 2022-12-12 18:05:37

Re: [Solved-ish] What installation reason should be used for make-depends?

#21 2022-12-13 00:04:14

Re: [Solved-ish] What installation reason should be used for make-depends?

#22 2022-12-13 13:01:32

Re: [Solved-ish] What installation reason should be used for make-depends?

#23 2022-12-13 15:40:43

Re: [Solved-ish] What installation reason should be used for make-depends?

Board footer