[cmake-developers] [CPack] CPackDeb and fakeroot

[Raffi Enficiaud]

Le 25/08/15 16:48, Eric Noulard a écrit :
> Hi guys,
>
> Some of my thoughts about this one.

Hi,

thanks you for your quick reply!

>
> 2015-08-25 15:42 GMT+02:00 Raffi Enficiaud
 >
> [snip]
>
> Yes but the may be interesting part should be in:
> /«BUILDDIR»/build_dir/_CPack_Packages/Linux/DEB/Deb.log
>
> which is not displayed in the previous file.

Sorry for that, I forgot to tell that everything works ok without 
pbuilder. So I believe this is the issue, I will check next time I build 
this.


>     Basically in my case, the debian/rule file calls cmake and cpack to
>     generate the deb packages.
>     pbuilder mimics a clean build environment that is used on Launchpad
>     for isolating the build, and I believe (not sure) it calls fakeroot
>     under the hood.
>
>
> pbuilder calls fakeroot for sure:
> In your log one can see:
>
> make[1]: Leaving directory `/«BUILDDIR»/build_dir'
>   fakeroot debian/rules binary-arch
> touch debian/files
> cpack --version
> cpack version 3.3.20150824
>
>
> [snip]
>
> The introduction of fakeroot usage for CPackDeb was made for that issue:
> http://public.kitware.com/Bug/view.php?id=10325
> with the small follow-up you cited:
> http://public.kitware.com/Bug/view.php?id=13118

Right, but again the main idea seems to be able to set the uid/guid 
properly in the tar.

>
> fakeroot is not used unless it is detected as installed on the system.
> The question in your case is, why is fakeroot installed AND not working
> when used in pbuilder.
>
> My guess is that pbuilder is ALREADY calling fakeroot and that fakeroot
> cannot be called from within fakerootED environnement (nested fakeroot
> is unsupported).

I also think this is the issue, nesting fakeroot is not supported.

>
> I would suggest checking (in CPackDeb generator code) whether if CPack
> has been called in a fakerootED environment. This can be done by
> checking whether if "FAKEROOTKEY" env var is defined or not.
> If fakeroot is already in action then one should not call fakeroot again
> (whatever the fakerootED user is).

I did not know about this key, that would be a nice/clean resolution to 
the problem.


>
> The #13700 bugs referred hereafter confirms this kind of issue:
> http://public.kitware.com/Bug/view.php?id=13700
>
>     - unifying the tool used for creating the tar: from the code in
>     cmCPackDebGenerator.cxx, some compression schemes use the native tar
>     while some others use the cmake tar.
>
>
> This is explained in Source/CPack/cmCPackDebGenerator.cxx
> // NOTE:
> // A debian package .deb is simply an 'ar' archive. The only subtle
> difference
> // is that debian uses the BSD ar style archive whereas most Linux
> distro have
> // a GNU ar.
> // See http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=161593 for more info
> // Therefore we provide our own implementation of a BSD-ar:
> static int ar_append(const char*archive,const std::vector<std::string>&
> files);
>
> I don't really known whether if this argument still apply nowadays
> and I let you read the discussion on bugs.debian.org
> <http://bugs.debian.org>.

Ok. Let's not burn our fingers on this direction then :)

>     What would be the best option for you?
>
>
>
> I let Domen answer for that, I was just jumping in to let you all know
> the bits of the story I remember.
>
>
>     I believe it would address this issues already in the backlog (and
>     help ppl deploy things on Launchpad with cmake):
>     - http://public.kitware.com/Bug/view.php?id=13700
>     - http://public.kitware.com/Bug/view.php?id=11766
>
>
> Like I said 13700 should be easy to fix by avoiding nested fakeroot call.
>
> 11766 is another story.
> I think that adding ownership option to cmake -E tar may be useful but
> not that urgent considering
> that most of these issues can be fixed in another easy mean.

If I understand the issue well, their concern
https://htcondor-wiki.cs.wisc.edu/index.cgi/tktview?tn=1863

was about doing some experiments for having root/root uid/guid + some 
fancy block size. root/root is ok now with fakeroot, and they abandoned 
the block_size fancy options.

The thing is that root/root implementation today is not fully ok due to 
the bug exposed on this thread (nested fakeroot).

> That said libarchive now seems to support "BSD tar"
> https://github.com/libarchive/libarchive/tree/master/tar
> and ownership using "set_ownership(struct archive_write_disk *)" API.
>
> so may be it's possible to get rid of the BSD tar implementation embedded in
> cmCPackDebGenerator.cxx and add appropriate calls to libarchive.
>

That would be a solution, but it is hard for me to see the gain of 
touching that many files instead of having the nice FAKEROOTKEY detection.

Thanks again!
Raffi