Re: [PATCH] dpkg-native: Avoid 'file changed' errors from tar

[Mark Hatle <mark.hatle@windriver.com>]

On 3/30/15 11:37 AM, Mark Hatle wrote:
> On 3/30/15 11:21 AM, Otavio Salvador wrote:
>> On Mon, Mar 30, 2015 at 1:02 PM, Richard Purdie
>> <richard.purdie@linuxfoundation.org> wrote:
>>> On Mon, 2015-03-30 at 12:02 -0300, Otavio Salvador wrote:
>>>> +When running do_package_write_deb, we have trees of symlinked files
>>>> +such as the dbg source files in ${PN}-dbg. If something makes another
>>>> +copy of one of those files (or deletes one), the number of links a file
>>>> +has changes and tar can notice this, e.g.:
>>>> +
>>>> +| DEBUG: Executing python function do_package_deb
>>>> +| dpkg-deb: building package `sed-ptest' in
>>>> `/media/build1/poky/build/tmp/work/i586-poky-linux/sed/4.2.2-r0/deploy-debs/i586/sed-ptest_4.2.2-r0.3_i386.deb'.
>>>> +| tar: ./usr/lib/sed/ptest/testsuite/tst-regex2: file changed as we read it
>>>> +| dpkg-deb: error: subprocess tar -cf returned error exit status 1
>>>> +
>>>> +Tar returns an error of 1 when files 'change' and other errors codes
>>>> +in other error cases. We tweak dpkg-deb here so that it ignores an exit
>>>> +code of 1 from tar. The files don't really change (and we have locking in
>>>> +place to avoid that kind of issue).
>>>>
>>>> This is exactly what I would expect for the long commit log. Sorry but
>>>> I strongly disagrese with you as the commit log in the patch does
>>>> connect with the short log so I still believe the commit log could be
>>>> improved.
>>>
>>> Well, I strong disagree with that, I don't believe it makes sense to cut
>>> and paste the same information into both places, sorry.
>>
>> I disagree someone should go into a patch header to understand it.
>>
> 
> I agree with Otavio here.  When generating both short and long changelogs, I
> always use the commit messages.  I don't inspect the contents of the changes to
> understand what happened.  Having to inspect means that I can't automate the
> process using the git commands.

Someone pointed out I might not have been as clear as I intended here.  I was
not saying I thought the commit and patch log need to match.  What I meant was
that I don't like seeing "See the patch header for details." in the commit
message, because it causes me problems with git generated changelogs.  (I have
developers/customers who then come back to me asking why I didn't include the
contents of the patch header in my generated changelogs.)

As for the content, the easiest is likely to duplicate the patch header into the
commit message... but of course that isn't required.

--Mark

> --Mark
>