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
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers
