Re: [PATCH v3 01/14] dpkg-raw: Respect file permissions defined by recipe if requested

[Henning Schild <henning.schild@siemens.com>]

Am Wed, 16 Jan 2019 20:09:33 +0100
schrieb Jan Kiszka <jan.kiszka@siemens.com>:

> On 16.01.19 16:24, Henning Schild wrote:
> > Am Wed, 16 Jan 2019 13:11:47 +0100
> > schrieb Jan Kiszka <jan.kiszka@siemens.com>:
> >   
> >> On 16.01.19 10:41, Henning Schild wrote:  
> >>> Am Wed, 16 Jan 2019 06:32:14 +0100
> >>> schrieb Jan Kiszka <jan.kiszka@siemens.com>:
> >>>      
> >>>> From: Jan Kiszka <jan.kiszka@siemens.com>
> >>>>
> >>>> dh_fixperms overwrites the permissions do_install may have
> >>>> defined. To avoid that, allow the recipe write to define an
> >>>> exception list via the PRESERVE_PERMS variable.
> >>>>
> >>>> Fixes: f301ccb2b5b1 ("meta/dpkg-raw: build raw packages like all
> >>>> others") CC: Henning Schild <henning.schild@siemens.com>
> >>>> Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
> >>>> ---
> >>>>    RECIPE-API-CHANGELOG.md       | 7 +++++++
> >>>>    meta/classes/dpkg-raw.bbclass | 9 ++++++++-
> >>>>    2 files changed, 15 insertions(+), 1 deletion(-)
> >>>>
> >>>> diff --git a/RECIPE-API-CHANGELOG.md b/RECIPE-API-CHANGELOG.md
> >>>> index 06a01e3..2bc1585 100644
> >>>> --- a/RECIPE-API-CHANGELOG.md
> >>>> +++ b/RECIPE-API-CHANGELOG.md
> >>>> @@ -124,3 +124,10 @@ updated hence recipes using them shouldn't
> >>>> be impacted per se.
> >>>>    These packages depend on a specific kernel. Its
> >>>> identification is now appended to the binary package names in
> >>>> the form "-${KERNEL_NAME}". +
> >>>> +### PRESERVE_PERMS needed with dpkg-raw for implicit file
> >>>> permission setting +
> >>>> +In order to use the same file permissions for an input file to a
> >>>> dpkg-raw +package on the build machine as well as on the target,
> >>>> its absolute target path +needs to be listed in the
> >>>> PRESERVE_PERMS variable (space-separated list of +files).
> >>>> Otherwise, default permissions are used. diff --git
> >>>> a/meta/classes/dpkg-raw.bbclass b/meta/classes/dpkg-raw.bbclass
> >>>> index 8d11433..42276e5 100644 --- a/meta/classes/dpkg-raw.bbclass
> >>>> +++ b/meta/classes/dpkg-raw.bbclass
> >>>> @@ -53,12 +53,19 @@ Description: ${DESCRIPTION}
> >>>>    EOF
> >>>>    }
> >>>>    
> >>>> +FIXPERM_EXCLUSIONS = \
> >>>> +    "${@' '.join(['-X ' + x for x in \
> >>>> +                  (d.getVar('PRESERVE_PERMS', False) or
> >>>> '').split()])}" +
> >>>>    deb_create_rules() {
> >>>>    	cat << EOF > ${S}/debian/rules
> >>>>    #!/usr/bin/make -f
> >>>> +
> >>>> +override_dh_fixperms:
> >>>> +	dh_fixperms ${FIXPERM_EXCLUSIONS}
> >>>> +  
> >>>
> >>> This should be done only if the variable is non-empty, to keep
> >>> that code generic. Also the variable name should maybe start with
> >>> DH_ or DEBIAN_.  
> >>
> >> I can change the naming, but I disagree regarding your other
> >> concern: dh_fixperms is by definition the default case if there is
> >> no override. Therefore
> >>
> >> override_dh_fixperms:
> >> 	dh_fixperms  
> > 
> > I would not be sure. Say a later step in some layers append would
> > want to set an actual override would the two conflict?  
> 
> There is no overlay method for rules files. You replace them, or
> patch them knowing how the original version looks like.

Exactly and if i wanted an actual override a >> would not work, because
i would have to patch out the useless one first. That is why this noop
should not be included.

Henning

> Jan
>