[CMake] Creating package

[Eric Noulard]

2012/5/27 Kornel Benko <kornel at lyx.org>:
>
>> > Now "dpkg -i xyzzy.deb" is working.
>>
>> Ok then, could you try with
>>
>> cmake -E tar zcvf data.tgz ./usr
>>
>> instead.
>
> This one produces the same _bad_ tar file.
>
> The error output of
>        #tar ztvf data.tgz> /dev/null
>                tar: Ignoring unknown extended header keyword `SCHILY.fflags'
>                tar: Ignoring unknown extended header keyword `SCHILY.fflags'
>                tar: Ignoring unknown extended header keyword `SCHILY.fflags'
>                tar: Ignoring unknown extended header keyword `SCHILY.fflags'

That's what I suspected.
There is some conflicting default setup between "system libarchive"
and "system tar command".

> Googling I found
>        http://www.redhat.com/archives/fedora-extras-list/2006-June/msg00734.html
> or this one
>        http://public.kitware.com/Bug/view.php?id=11176
> which looks more related.
>
> Following the last link to
>        http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=22fb266d
> is interesting too.

Thanks you for digging this up,
I'll have a more close look at CPackDeb code because there should
be some "BSD tar" code inside the cmCPackDebGenerator.cxx which is supposed
to enhance tar portability issue.

This code is NOT using libarchive but obviously some part of CPackDeb
is using cmake -E tar / libarchive.

I'll try to either always use libarchive with "enforced" options
(which may not be the same as the one used by cmake -E tar)
or always use the builtin BSD tar.

>> I think I've seen some bug like this in the past I'll check the
>> mailing list archive
>> and the CMake bug tracker.
>>
>> Found it: http://www.cmake.org/Bug/view.php?id=8790
>> not really the same issue but who knows...
>>
>> I'll try to get my hand on an Ubuntu 12.04 box to check whether if I
>> can reproduce the problem.
>>
>> This deserve a bug report to Ubuntu
>> https://launchpad.net/cmake
>> and may be we will get one for CMake when the ubuntu package
>> maintainer get your report.
>>
> I feared, you could propose something like this :)

Don't be afraid :-]
I don't want to push away the bug report but CMake source code
convey inside its source tree some external libraries (libarchive, zlib etc...)
in order to be able to:
   1) have greater portability
   2) have less 'external' dependencies (in fact there is almost none)
   3) ease testing on various platform in a consistent way.

I understand the will of distro packager to build cmake using "SYSTEM" lib
but (I think that) this cannot be tested on all system combination so
may be they should do some regression testing when doing that.
May be we can suggest that distros packager run a CMake dashboard
with their own "configuration" problem with this being that they may
apply patches that may triggers red flags which may not be upstream
concerns...

May be we should add a test (in CMake test suite) that

1) create tar using cmake -E tar
    and untar it using system tar
2) create a tar using system tar
    and untar it using cmake -E tar

That could help us (and packager if they run the CMake test suite)  to
catch this kind of issue.
Currently there is a "TarTest" (see <CMake-Source>/Tests/TarTest
but it's "only" testing whether if the cmake -E tar command is able to
work with itself.


-- 
Erk
Le gouvernement représentatif n'est pas la démocratie --
http://www.le-message.org