Issue with another downstream over DESTDIR builds

Issue with another downstream over DESTDIR builds

[Brian Inglis]

Hi folks, [Please Reply All to CC me as ISP blocking Cygwin lists]

I previously submitted a patch upstream to add DESTDIR when creating 
package symlinks so cygport builds work without patches.

Now another downstream is disputing that, requesting the patch be 
reverted, saying that symlink targets are contents and should always be 
from the non-DESTDIR native source as per GNU "rules" in the autobook.

We agreed to request other more experienced opinions on this issue from 
our support groups and report back.

I am asking the perhaps more experienced professional maintainers to 
provide their considered opinion on this issue, demonstrated by the 
reversion patch below.

> The link's target must not include $(DESTDIR), otherwise this ends up
> included in the shipped link. Linking the theoretical target gives the
> correct result.
> 
> --- a/Makefile.in
> +++ b/Makefile.in
> @@ -115,7 +115,7 @@
>    	$(INSTALL_DATA) $(srcdir)/definitions.units $(DESTDIR)@UDAT@definitions.units
>    	-rm -f $(DESTDIR)@UDAT@currency.units
>    	$(INSTALL_DATA) $(srcdir)/currency.units $(DESTDIR)@CDAT@currency.units
> -	if [ $(DESTDIR)@CDAT@ != $(DESTDIR)@UDAT@ ];then ln -sf $(DESTDIR)@CDAT@currency.units $(DESTDIR)@UDAT@currency.units;fi
> +	if [ $(DESTDIR)@CDAT@ != $(DESTDIR)@UDAT@ ];then ln -sf @CDAT@currency.units $(DESTDIR)@UDAT@currency.units;fi
>    	$(INSTALL_DATA) $(srcdir)/locale_map.txt $(DESTDIR)@UDAT@locale_map.txt
>    	if test $(HAVE_PYTHON) = yes; then \
>    	  $(INSTALL_PROGRAM) units_cur_inst $(DESTDIR)$(bindir)/`echo units_cur|sed '$(transform)'`;fi

-- 
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

This email may be disturbing to some readers as it contains
too much technical detail. Reader discretion is advised.
[Data in binary units and prefixes, physical quantities in SI.]

Re: Issue with another downstream over DESTDIR builds

[Jon Turney]

On 29/09/2022 20:15, Brian Inglis wrote:
> Hi folks, [Please Reply All to CC me as ISP blocking Cygwin lists]
> 
> I previously submitted a patch upstream to add DESTDIR when creating 
> package symlinks so cygport builds work without patches.
> 
> Now another downstream is disputing that, requesting the patch be 
> reverted, saying that symlink targets are contents and should always be 
> from the non-DESTDIR native source as per GNU "rules" in the autobook.

A link to this discussion would be useful.

> We agreed to request other more experienced opinions on this issue from 
> our support groups and report back.
> 
> I am asking the perhaps more experienced professional maintainers to 
> provide their considered opinion on this issue, demonstrated by the 
> reversion patch below.
> 
>> The link's target must not include $(DESTDIR), otherwise this ends up
>> included in the shipped link. Linking the theoretical target gives the
>> correct result.
>>
>> --- a/Makefile.in
>> +++ b/Makefile.in
>> @@ -115,7 +115,7 @@
>>        $(INSTALL_DATA) $(srcdir)/definitions.units 
>> $(DESTDIR)@UDAT-DGkERpxY6iylqvY/pMPnfPU/3Eu2kcEP@public.gmane.org
>>        -rm -f $(DESTDIR)@UDAT-kLXayl1e/4yKtURqy47hLg@public.gmane.org
>>        $(INSTALL_DATA) $(srcdir)/currency.units 
>> $(DESTDIR)@CDAT-kLXayl1e/4yKtURqy47hLg@public.gmane.org
>> -    if [ $(DESTDIR)@CDAT@ != $(DESTDIR)@UDAT@ ];then ln -sf 
>> $(DESTDIR)@CDAT-kLXayl1e/4yKtURqy47hLg@public.gmane.org 
>> $(DESTDIR)@UDAT-kLXayl1e/4yKtURqy47hLg@public.gmane.org;fi
>> +    if [ $(DESTDIR)@CDAT@ != $(DESTDIR)@UDAT@ ];then ln -sf 
>> @CDAT-kLXayl1e/4yKtURqy47hLg@public.gmane.org 
>> $(DESTDIR)@UDAT-kLXayl1e/4yKtURqy47hLg@public.gmane.org;fi
>>        $(INSTALL_DATA) $(srcdir)/locale_map.txt 
>> $(DESTDIR)@UDAT@locale_map.txt
>>        if test $(HAVE_PYTHON) = yes; then \
>>          $(INSTALL_PROGRAM) units_cur_inst $(DESTDIR)$(bindir)/`echo 
>> units_cur|sed '$(transform)'`;fi
> 

This patch looks correct.

Think of it this way: --prefix etc. configures the location of the 
installed files, DESTDIR selects a temporary staging directory that the 
files are placed into (e.g. before packaging)

So, targets of symlinks which are absolute paths should not contain DESTDIR.

Re: Issue with another downstream over DESTDIR builds

[Brian Inglis]

On 2022-09-30 06:11, Jon Turney wrote:
> On 29/09/2022 20:15, Brian Inglis wrote:
>> Hi folks, [Please Reply All to CC me as ISP blocking Cygwin lists]
>>
>> I previously submitted a patch upstream to add DESTDIR when creating 
>> package symlinks so cygport builds work without patches.
>>
>> Now another downstream is disputing that, requesting the patch be 
>> reverted, saying that symlink targets are contents and should always 
>> be from the non-DESTDIR native source as per GNU "rules" in the autobook.

> A link to this discussion would be useful.

Thanks Jon,

Unfortunately the upstream package does not use a list so it is all DM.

>> We agreed to request other more experienced opinions on this issue 
>> from our support groups and report back.
>>
>> I am asking the perhaps more experienced professional maintainers to 
>> provide their considered opinion on this issue, demonstrated by the 
>> reversion patch below.
>>
>>> The link's target must not include $(DESTDIR), otherwise this ends up
>>> included in the shipped link. Linking the theoretical target gives the
>>> correct result.
>>>
>>> --- a/Makefile.in
>>> +++ b/Makefile.in
>>> @@ -115,7 +115,7 @@
>>>        $(INSTALL_DATA) $(srcdir)/definitions.units 
>>> $(DESTDIR)@UDAT-DGkERpxY6iylqvY/pMPnfPU/3Eu2kcEP@public.gmane.org
>>>        -rm -f $(DESTDIR)@UDAT-kLXayl1e/4yKtURqy47hLg@public.gmane.org
>>>        $(INSTALL_DATA) $(srcdir)/currency.units 
>>> $(DESTDIR)@CDAT-kLXayl1e/4yKtURqy47hLg@public.gmane.org
>>> -    if [ $(DESTDIR)@CDAT@ != $(DESTDIR)@UDAT@ ];then ln -sf 
>>> $(DESTDIR)@CDAT-kLXayl1e/4yKtURqy47hLg@public.gmane.org 
>>> $(DESTDIR)@UDAT-kLXayl1e/4yKtURqy47hLg@public.gmane.org;fi
>>> +    if [ $(DESTDIR)@CDAT@ != $(DESTDIR)@UDAT@ ];then ln -sf 
>>> @CDAT-kLXayl1e/4yKtURqy47hLg@public.gmane.org 
>>> $(DESTDIR)@UDAT-kLXayl1e/4yKtURqy47hLg@public.gmane.org;fi
>>>        $(INSTALL_DATA) $(srcdir)/locale_map.txt 
>>> $(DESTDIR)@UDAT@locale_map.txt
>>>        if test $(HAVE_PYTHON) = yes; then \
>>>          $(INSTALL_PROGRAM) units_cur_inst $(DESTDIR)$(bindir)/`echo 
>>> units_cur|sed '$(transform)'`;fi

> This patch looks correct.
> 
> Think of it this way: --prefix etc. configures the location of the 
> installed files, DESTDIR selects a temporary staging directory that the 
> files are placed into (e.g. before packaging)
> 
> So, targets of symlinks which are absolute paths should not contain 
> DESTDIR.

I think I'll try and see what happens in cygport, report back here or 
for more feedback, and if no issues, okay with upstream.

-- 
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

This email may be disturbing to some readers as it contains
too much technical detail. Reader discretion is advised.
[Data in binary units and prefixes, physical quantities in SI.]

Re: Issue with another downstream over DESTDIR builds

[Brian Inglis]

On 2022-09-30 12:38, Brian Inglis wrote:
> On 2022-09-30 06:11, Jon Turney wrote:
>> On 29/09/2022 20:15, Brian Inglis wrote:
>>> Hi folks, [Please Reply All to CC me as ISP blocking Cygwin lists]
>>>
>>> I previously submitted a patch upstream to add DESTDIR when creating 
>>> package symlinks so cygport builds work without patches.
>>>
>>> Now another downstream is disputing that, requesting the patch be 
>>> reverted, saying that symlink targets are contents and should always 
>>> be from the non-DESTDIR native source as per GNU "rules" in the 
>>> autobook.
> 
>> A link to this discussion would be useful.
> 
> Thanks Jon,
> 
> Unfortunately the upstream package does not use a list so it is all DM.
> 
>>> We agreed to request other more experienced opinions on this issue 
>>> from our support groups and report back.
>>>
>>> I am asking the perhaps more experienced professional maintainers to 
>>> provide their considered opinion on this issue, demonstrated by the 
>>> reversion patch below.
>>>
>>>> The link's target must not include $(DESTDIR), otherwise this ends up
>>>> included in the shipped link. Linking the theoretical target gives the
>>>> correct result.
>>>>
>>>> --- a/Makefile.in
>>>> +++ b/Makefile.in
>>>> @@ -115,7 +115,7 @@
>>>>        $(INSTALL_DATA) $(srcdir)/definitions.units 
>>>> $(DESTDIR)@UDAT-DGkERpxY6iylqvY/pMPnfPU/3Eu2kcEP@public.gmane.org
>>>>        -rm -f $(DESTDIR)@UDAT-kLXayl1e/4yKtURqy47hLg@public.gmane.org
>>>>        $(INSTALL_DATA) $(srcdir)/currency.units 
>>>> $(DESTDIR)@CDAT-kLXayl1e/4yKtURqy47hLg@public.gmane.org
>>>> -    if [ $(DESTDIR)@CDAT@ != $(DESTDIR)@UDAT@ ];then ln -sf 
>>>> $(DESTDIR)@CDAT-kLXayl1e/4yKtURqy47hLg@public.gmane.org 
>>>> $(DESTDIR)@UDAT-kLXayl1e/4yKtURqy47hLg@public.gmane.org;fi
>>>> +    if [ $(DESTDIR)@CDAT@ != $(DESTDIR)@UDAT@ ];then ln -sf 
>>>> @CDAT-kLXayl1e/4yKtURqy47hLg@public.gmane.org 
>>>> $(DESTDIR)@UDAT-kLXayl1e/4yKtURqy47hLg@public.gmane.org;fi
>>>>        $(INSTALL_DATA) $(srcdir)/locale_map.txt 
>>>> $(DESTDIR)@UDAT@locale_map.txt
>>>>        if test $(HAVE_PYTHON) = yes; then \
>>>>          $(INSTALL_PROGRAM) units_cur_inst $(DESTDIR)$(bindir)/`echo 
>>>> units_cur|sed '$(transform)'`;fi
> 
>> This patch looks correct.
>>
>> Think of it this way: --prefix etc. configures the location of the 
>> installed files, DESTDIR selects a temporary staging directory that 
>> the files are placed into (e.g. before packaging)
>>
>> So, targets of symlinks which are absolute paths should not contain 
>> DESTDIR.
> 
> I think I'll try and see what happens in cygport, report back here or 
> for more feedback, and if no issues, okay with upstream.

Thanks Jon for your help,

Tried builds with the upstream patch reversion, and all built okay 
locally and under CI, and install and run okay, so I admitted my 
mistake, agreed with their patch, and apologized to upstream and the 
other downstream for the noise and time wasted.

-- 
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

This email may be disturbing to some readers as it contains
too much technical detail. Reader discretion is advised.
[Data in binary units and prefixes, physical quantities in SI.]