FS#41117 - [devtools] [PATCH] makechrootpkg: Add -P for --private-network

Attached to Project: Arch Linux
Opened by Olivier Brunel (jjacky) - Sunday, 06 July 2014, 17:17 GMT
Last edited by freswa (frederik) - Sunday, 13 September 2020, 11:31 GMT
Task Type Feature Request
Category Arch Projects
Status Closed
Assigned To Pierre Schmitz (Pierre)
Dave Reisner (falconindy)
Architecture All
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

This allows to build a package in a chroot without network connectivity. The
point for me being mainly that I don't want pacman to download anything when
installing {make,}dependencies, i.e. everything needed must already be in
pacman's cache. If it's not the case, it means I missed something/did something
wrong somewhere, and this makes it easy to notice.

This is notably useful because I have a few packages I build myself w/ different
options/dependencies, and so when building packages I don't want pacman to e.g.
pull a dependency of foo (instead, I'll have to have my foo-jjk package, which
conflicts & provides foo, to be installed before hand), otherwise this could
lead to issues, e.g. built package being linked to bar when it shouldn't,
because bar was installed as a dependency of foo.
   0001-makechrootpkg-Add-P-for-... (1.8 KiB)
This task depends upon

Closed by  freswa (frederik)
Sunday, 13 September 2020, 11:31 GMT
Reason for closing:  No response
Comment by Daniel Micay (thestinger) - Sunday, 06 July 2014, 17:32 GMT
I don't understand the purported use case for this. Relying on packages not being in the cache to prevent an issue is strange, since everything is listed in the output. I also don't understand why a dependency being pulled in recursively would be a bug, that's just how package management works.
Comment by Olivier Brunel (jjacky) - Sunday, 06 July 2014, 17:49 GMT
Everything might be listed in the output, but when building everything is automatic, since --no-confirm is used. So I'd have to quickly kill things while pacman was already downloading something I don't want to be downloaded.

And I'm not saying a dependency being pulled would be a bug, just something that I don't want happening here. (Or, a bug on my end only.) E.g. if the package to be built depends on gtk3 (or has a dependency that does), I don't want pacman to end up downloading/installing it, I'd want to have another package, providing gtk3 but with maybe a different set of dependencies as the official gtk3 package, to be installed instead.

Using --private-network, in case e.g. I missed the gtk3 dependency and failed to install my gtk3-jjk package in the chroot, I simply get pacman erroring out as it failed to download the gtk3 package. Everything is fast, clear, obvious. (This also happens without any flag, when building on a computer with no internet.)

Without the flag, either I see it as it is being downloaded and I get a chance to kill pacman and fix things; or I don't and it's only afterwards, after the whole package was successfully built in the chroot, that I need to go over things & realize what happened and need to start everything all over again.
Comment by Dave Reisner (falconindy) - Sunday, 06 July 2014, 18:33 GMT
Your goal and your proposed fix don't really seem related. If all you want to do is prevent the network from being functional, then bind mount an empty resolv.conf into the chroot. You can already do this with the existing flags.
Comment by Olivier Brunel (jjacky) - Sunday, 06 July 2014, 20:04 GMT
Well, I'm not sure why you say they don't seem related, in fact I originally thought I'd have to configure something in the chroot, only to find, as I was reading some man pages, the --private-network option of systemd-nspawn which seems (to me) to do exactly what I want/need. That's why I decided to simply use it.

(Also, I quickly just tried bind mounting an empty resolv.conf and the network remained functional in the container.)
Comment by Eli Schwartz (eschwartz) - Tuesday, 01 August 2017, 21:54 GMT
This patch doesn't even achieve the stated goals, because the existence of network connectivity has nothing to do with whether or not the "wrong" packages already exist in the cache. It also seems like a highly-specific use case that only you would ever need, which is an argument for solving it another way.

Also, if you want to build packages against foo-jjk instead of foo, the best way to do this is via makedepends+=('foo-jjk').

...

OTOH if makepkg supported a --confirm flag to negate a previous --noconfirm flag, you'd have the option of manually approving things.

So I really feel this is an xyproblem.

Loading...