Re: [ptxdist] ROOTDIR and image packages

[Michael Olbrich <m.olbrich@pengutronix.de>]

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
ptxdist@pengutronix.de