Optionally don't copy sources around #765
Conversation
|
works with eg https://github.com/openSUSE/aaa_base/ but also yast packages |
|
The overlayfs might turn out to be cumbersome. The other alternative might be bind mount and creating the abuild user with matching uid of the calling user. So object files etc don't remain in the chroot. |
lnussel
force-pushed
the
awesome
branch
2 times, most recently
from
c91a5d6
to
53295b0
Compare
|
interesting, but what is actually the use case here? For local development purposes the bind mount might be indeed the better way (to get changes from the build root back). For simple build tasks one should not use chroot anymore. (It is our goal to go away from chroot by default, so I wonder if it is useful to merge chroot specific functionality atm.) |
|
I want to build packages directly from git. Without having to install the build deps in my system and without the time consuming repacking of sources. Yes, ideally a chroot into the build env and editing the sources there should modify the checkout. Have to figure out whether there's a solution as mentioned. Anyway one has to pick the poison. It's fine to build normal packages with qemu by default but if certain features are important and only chroot can provide that so it be IMO. I mean I'm exactly in the same situation. Forced to chroot with this :-) |
|
On Montag, 24. Januar 2022, 08:58:14 CET Ludwig Nussel wrote:
I want to build packages directly from git.
To be exact, building from a git where upstream sources and build descriptions are fully under your control.
Since building from git is possible without, but usually you get sources from some resource which is not under
your control.
Also the resulting package is not usable in a distribution currently (no full src.rpm).
So, this is just for personal development purposes on a few packages?
Or do you see a broader usability somewhere?
In any case, we would need to bring it in sync with asset handling and some reworked VM handling
which is in our queue (which works via multiple volumes and snapshots for speed optimizations)
Maybe we should have some personal discussion about it...
… Without having to install the build deps in my system and without the time consuming repacking of sources. Yes, ideally a chroot into the build env and editing the sources there should modify the checkout. Have to figure out whether there's a solution as mentioned.
Also I actually started with qemu full unprivileged build (pr pending to make that work) but I didn't find a good solution to solve the original problem with qemu. The fat emulation doesn't sound right and virtiofsd has to run as root. Suggestions welcome.
Anyway one has to pick the poison. It's fine to build normal packages with qemu by default but if certain features are important and only chroot can provide that so it be IMO. I mean I'm exactly in the same situation. Forced to chroot with this :-)
--
Adrian Schroeter ***@***.***>
Build Infrastructure Project Manager
SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg) Geschäftsführer: Ivo Totev
|
|
This is for local development, doesn't follow a bigger plan. And yes, it works only for packages that are 100% in git without extra tarballs etc. Like eg aaa_base. |
|
using 9pfs for kvm build to get access to calling user's source dir seems to work. need to include |
lnussel
force-pushed
the
awesome
branch
3 times, most recently
from
75a5086
to
2992f80
Compare
|
added --rpmbopts to avoid spec specific options. Not sure it's pretty though. Requires something like |
|
I also filed a request to include 9p in kernel-obs-build |
|
I've rebased and checked this one again. Basically works. A minor issue is that |
Apply build time modifications to the spec file in a separate file. Allows to link original sources.
Don't re-create fs image when building as user Don't re-create swap
Use bind mount resp qemu 9p support to directly mount the source directory into the build environment. This allows for faster turnaround times for interactive buildling.
With --no-init the disk image won't be changed, ie build.data can't be updated either. Means it's not possible to eg change --stage for quick development cycles either. So additionally pass build.data via qemu_fwcfg and prefer that one if it exists.
mkfs needs to see the files it copies into the fs as owned by root. Otherwise the whole fs tree would be owned by the calling user. Doesn't matter too much when setting up the build root initially as rpm is called inside anyway to fix everything. However, when reusing an image suddenly all ownerships would change.
lnussel
force-pushed
the
awesome
branch
2 times, most recently
from
1275793
to
db0bf8d
Compare
make VM builds mount the original source directory using 9pfs. This avoids copying files around which is handy for large files and also development from a git tree in combination with --rpm-build-in-place. As compilation takes place in the current directory, this allows fast edit/compile cycles through the build script.