[PATCH 2/3] tar01 and tar02: Do not generate tar archives

[Chris Johns]

On 19/11/19 5:19 pm, Sebastian Huber wrote:
> On 19/11/2019 02:15, Chris Johns wrote:
>> On 18/11/19 6:10 pm, Sebastian Huber wrote:
>>> This simplifies the build and avoids some host dependencies, e.g.
>>> availability of symbolic links in the host file system.  Makes it
>>> possible to validate time stamps.
>>>
>>> Update #3818.
>>> ---
>>>   testsuites/libtests/Makefile.am        |  41 ++++++++-------------------------
>>>   testsuites/libtests/tar01/tar01.tar    | Bin 0 -> 10240 bytes
>>>   testsuites/libtests/tar01/tar01.tar.gz | Bin 0 -> 296 bytes
>>>   testsuites/libtests/tar01/tar01.tar.xz | Bin 0 -> 340 bytes
>>>   testsuites/libtests/tar02/tar02.tar    | Bin 0 -> 10240 bytes
>>>   5 files changed, 9 insertions(+), 32 deletions(-)
>>>   create mode 100644 testsuites/libtests/tar01/tar01.tar
>>>   create mode 100644 testsuites/libtests/tar01/tar01.tar.gz
>>>   create mode 100644 testsuites/libtests/tar01/tar01.tar.xz
>>>   create mode 100644 testsuites/libtests/tar02/tar02.tar
>>
>> How are the tar files created?
> 
> I copied the files from my build tree to the source tree.

OK, makes sense.

>> How do we capture what is in them and how to regenerate them? 
> 
> Ok, this is an issue. You have to unpack them, change your stuff, and re-create
> them by hand.

Hmm. We need to capture what it is we want in the tar file, for example the
script to create it could be held in it.

>> At the moment I
>> can inspect all of this test via cgit. The idea of downloading and checking can
>> be problematic depending on the host and set up, ie a tablet.
>>
>> Has the generation of these files been checked on more than Linux?
> 
> I doubt that anyone did run the tests using a FAT file system on the host for
> example.

Well maybe not FAT but I have on Windows. Build the tools, build RTEMS, run the
test. It is this simplicity I like.

>> How do we check updated host tools have not broken the code we have in RTEMS?
> 
> I would consider it a serious bug in a future host pax tool if it breaks the
> RTEMS code.

We have had issues in the past so it can happen and on Windows I have seen a few
times over the years.

>> I am concerned we are loosing some of the checking that we currently have moving
>> to this approach. The symlink issue is a real one so maybe we hold a single tar
>> to check that works.
> 
> With the dynamic generation of the archive we cannot test the file permissions,
> the group and user IDs, and the time stamps.

Ah yes this is a good point. Could we have a single tar file that tests those
parts and others that are generated to test the host and RTEMS code?

Chris