Hi, On Tue, Oct 16, 2018 at 12:31:52PM +0000, Baeuerle, Florian wrote: > I making heavy use of image packages with collections. Some images select and > install packages that are in conflict with each other due to installing the > same > file. This creates problems when they are targetinstalled to ROOTDIR > concurrently. I often get errors like this: > > install alternative: > src=foo/configs/platform-imx27/projectroot/etc/rauc/system.conf > dst=/etc/rauc/system.conf > owner=0 > group=0 > permissions=0644 > > chmod: cannot access '/home/jenkins/workspace/foo/platform- > imx27/root/etc/rauc/system.conf': No such file or directory > Error: install_alternative failed! > > xpkg_finish: failed. > > /home/jenkins/workspace/foo/configs/platform-imx27/rules/image-squashfs- > jaeger90-release.make:45: recipe for target > '/home/jenkins/workspace/foo/platform-imx27/state/image-squashfs-jaeger90- > release.targetinstall' failed > make: *** [/home/jenkins/workspace/foo/platform-imx27/state/image-squashfs- > jaeger90-release.targetinstall] Error 1 > make: *** Waiting for unfinished jobs.... > > The same file is touched by the -devel package. I suppose that there is a race > condition between those two packages. > > Please ignore the fact that I am creating and installing an extra package via > an > image package, this works fine. The problem also exists for "normal" packages. > > > So my question is: How should that be fixed? > > My proposals are: > > 1. Add an option to disable nfsroot / ROOTDIR > -> Image packages can have their own exclusive nfsroot > -> With image packages the contents of ROOTDIR are not really useful
I would accept a patch for this. > 2. Lock ROOTDIR similar as was done with sysroot in commit 82d0922 > -> Might slow down targetinstall for no use I think I can do some tests with this. To check what the impact is. For sysroot I didn't meassure a difference, probably because it's I/O limited anyways. It could be different here, because creating debug files happens here too. > 3. Lock each and every file or directory > -> Could be rather complex for no real use We would need to rewrite the whole code: We need make all operations for a file under the lock (install + chmod etc.). But that will include debug file generation right now. And I think that would be the main benefit of this version. So probably 1. or 2. > Currently, I use something like "@sleep 3" in .targetinstall, but this just > sucks and it even fails sometimes. I've added some extra dependencies among the targetinstall stages for stuff like this. It's not so nice, because some pacakges are recreated unnecessarily. Michael -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 | Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 | _______________________________________________ ptxdist mailing list [email protected]
