package: piuparts submitter: Alexander Thomas <alexander.tho...@esaturnus.com> x-debbugs-cc: Alexander Thomas <alexander.tho...@esaturnus.com>
Hi Alexander,
thanks for your bug report, I turned it into one so we don't loose track
of it!
On Fri, Oct 14, 2016 at 03:53:49PM +0200, Alexander Thomas wrote:
> In July 2014, a patch was included to use `cp -al` instead of `cp -ax`
> when the -e option is used and the chroot is on the same filesystem as
> where piuparts is run. I wonder why this was included without making
> it optional, or maybe why it was included at all.
a quick grep in todays piuparts for "cp -al" (and for "cp" too) reveal no hits.
can you confirm that piuparts 0.72 is affected?
> Hard-linking the chroot makes little sense unless there is a guarantee
> that none of the existing files will be modified. The only difference
> with just running the test in the provided chroot itself, is that new
> or deleted files will not be reflected in the original directory.
> Modifications to existing files however will be reflected in the
> original chroot, because of the hard links. Because the whole point of
> piuparts testing is to detect unexpected changes, at some point a
> naughty package will clobber existing files, and this change will
> persist.
> Maybe the submitter of the patch mistook `cp -al` as a copy-on-write,
> or didn't mind that this would make the -e option of piuparts
> destructive.
>
> In our setup,
could you maybe expand a little bit on this, I'm curious (and having
users is motivating!
> we perform multiple separate runs of piuparts, and it is
> essential to start from a pristine copy of the same chroot every time.
> We use the -e option to avoid having to re-generate and customize the
> chroot for every test, or unpack the same tarball over and over again.
> It is essential that the original chroot is not modified. Relying on
> hard links method breaks this workflow unless we wrap every test
> inside yet another cp -ax, which again makes everything slower.
>
> If anyone sees a valid use case for the hard linked chroot, an option
> to enable it separately should be added. Otherwise this patch should
> be reverted.
reading #754878 it tells me this code should only be used with the
--existing-chroot option.
Right now I'm too tired to actually look at the code itself… Git patches
are also much welcome too! ;-)
> --
> Alexander Thomas
Thanks again! :)
--
cheers,
Holger
signature.asc
Description: Digital signature
