Hi,

On 08.09.2017 10:30, Henning Schild wrote:
> Am Tue, 5 Sep 2017 10:37:48 +0300
> schrieb Alexander Smirnov <asmirnov@ilbers.de>:
> 
>> Hi,
>>
>>>> On 09/04/2017 05:11 PM, Alexander Smirnov wrote:  
>>>>> On 08/30/2017 10:03 PM, Henning Schild wrote:  
>>>>>> Issue:
>>>>>> The unpacker in dpkg is not generic since it does not unpack to
>>>>>> WORKDIR, so it can not be pulled into a more generic class to
>>>>>> make it available for other users.
>>>>>>  
>>>>>
>>>>> As I already wrote to mail-list, WORKDIR and BUILDROOT are
>>>>> different folders, and there was the reason to do so.  
>>>>
>>>> Yes we (Henning and I) get that. That is the reason why the patch 
>>>> includes the line:
>>>>
>>>> +WORKDIR_task-unpack = "${BUILDROOT}"
>>>>
>>>> That means that only for the unpack task in the dpkg.bbclass the 
>>>> variable WORKDIR is set to the BUILDROOT variable. This makes the 
>>>> unpack step more generic so that it can be moved to the base
>>>> class. Essentially removing the dependency of the unpack task to
>>>> the dpkg class.  
>>>
>>> Does this mean that "log.do_unpack" and "run.do_unpack" will be
>>> stored in buildchroot? Let me check this.
>>>   
>>
>> Yes it does:
>>
>> ls 
>> isar/build/tmp/work/buildchroot/debian-wheezy-armhf/rootfs/home/builder/hello/temp/
>>
>> log.do_unpack
>> log.do_unpack.19557
>> log.task_order
>> run.do_unpack
>> run.do_unpack.19557
>>
>> While it's assumed that they should be stored in: 
>> isar/build/tmp/work/hello-0.1+g7f35942-1-r0/temp/
> 
> I think i am starting to understand the whole problem with the WORKDIR
> and the BUILDROOT better. Instead of the unpacking to BUILDROOT or
> messing with WORKDIR i think we should have a new task after do_unpack
> 
> So instead of do_unpack -> BUILDROOT
> 
> do_unpack archive -> WORKDIR
> do_copy_to_buildroot WORKDIR -> BUILDROOT
> 
> That should keep all the logs in an unmodified WORKDIR and the unpacker
> would always extract to there. Classes that need the files to live in
> BUILDROOT would have to include the task do_copy_to_buildroot.

I agree with that separating those into two tasks is the better
solution, but I don't like the 'copy_to_buildroot' name, because it
limits possible implementations of this task by that name. For instance
you could, and maybe even should, use a bind mount instead of copying
the files around.

Something like "populate" or "prepare" as a prefix sounds a bit better IMO.

Cheers,
Claudius

-- 
DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-54 Fax: (+49)-8142-66989-80 Email: ch@denx.de

           PGP key: 6FF2 E59F 00C6 BC28 31D8 64C1 1173 CB19 9808 B153
                             Keyserver: hkp://pool.sks-keyservers.net