GNU bug report logs - #61674
[PATCH 0/4] gnu: stellarium: Enable ShowMySky.

Previous Next

Full log

View this message in rfc822 format

From: Maxim Cournoyer <maxim.cournoyer <at> gmail.com>
To: Simon Tournier <zimon.toutoune <at> gmail.com>
Cc: Ludovic Courtès <ludo <at> gnu.org>, Sharlatan Hellseher <sharlatanus <at> gmail.com>, 61674 <at> debbugs.gnu.org
Subject: [bug#61674] [PATCH 0/4] gnu: stellarium: Enable ShowMySky.
Date: Fri, 03 Mar 2023 10:54:11 -0500

Hi Simon,

Simon Tournier <zimon.toutoune <at> gmail.com> writes:

> Hi,
>
> On Fri, 3 Mar 2023 at 11:49, Ludovic Courtès <ludo <at> gnu.org> wrote:
>
>> This is so that the ‘replacement’ field of ‘calcmysky’, when there is
>> one, inherits the same transformations in ‘calcmysky-qt5’.  Quoth the
>> ‘package/inherit’ docstring:
>>
>>   Like (package (inherit P) OVERRIDES ...), except that the same
>>   transformation is done to the package P's replacement, if any.  P must
>>   be a bare identifier, and will be bound to either P or its replacement
>>   when evaluating OVERRIDES.
>
> Thanks for the explanations but it is still unclear.  Sorry to be slow.
>
> It is not clear for me why you choose one over the other.  From my
> current understanding, I would be tempted to always use
> 'package/inherit' and never plain 'inherit'.

I also got confused by that in the past;  The way I process it
internally now is this:

If the inheritance is for *same-source/same-version* variants of a
package, they should use package/inherit, as any security issues found
in the parent package should also be applied to that package (since they
use the same source).  Otherwise, plain 'inherit' should be used
(e.g. for newer version variants).

I hope that helps!

Yours in slowness,

-- 
Maxim

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.