[bug#61674,1/4] gnu: Add calcmysky.

* gnu/packages/astronomy.scm (calcmysky, calcmysky-qt5): New variables.
---
 gnu/packages/astronomy.scm | 59 ++++++++++++++++++++++++++++++++++++++
 1 file changed, 59 insertions(+)

On Sun, Feb 26, 2023 at 12:44:03AM +0000, Sharlatan Hellseher wrote:
> * gnu/packages/astronomy.scm (calcmysky, calcmysky-qt5): New variables.

Thanks for these patches!

> +  #:use-module ((guix build utils) #:select (alist-replace))
[...]
> +(define-public calcmysky-qt5
> +  (package
> +    (inherit calcmysky)
> +    (name "calcmysky-qt5")
> +    (arguments
> +     (list #:configure-flags
> +           #~(list "-DQT_VERSION=5"
> +                   "-DCMAKE_CXX_FLAGS=-fPIC")))
> +    (inputs
> +     (alist-replace "qtbase" (list qtbase-5)
> +                    (package-inputs calcmysky)))

Can you try rewriting this using modify-inputs, rather than
alist-replace?

https://guix.gnu.org/manual/devel/en/html_node/Defining-Package-Variants.html#Defining-Package-Variants

Feel free to ask for help if you get stuck.

Hi!

Thanks for a nice patch series!

Sharlatan Hellseher <sharlatanus@gmail.com> skribis:

> * gnu/packages/astronomy.scm (calcmysky, calcmysky-qt5): New variables.

[...]

> +    (license license:gpl3)))

Please double-check whether something explicitly says “version 3 only”;
if not, it’s ‘gpl3+’.

> +(define-public calcmysky-qt5
> +  (package
> +    (inherit calcmysky)

Rather:

  (package/inherit calcmysky
    (name "calcmysky-qt5")
    …)

> +    (inputs
> +     (alist-replace "qtbase" (list qtbase-5)
> +                    (package-inputs calcmysky)))

Instead of ‘alist-replace’, write

  (modify-inputs (package-inputs calcmysky)
    (replace "qtbase" qtbase-5))

You can remove the corresponding #:use-module form at the top.

Ludo’.

Hi Ludo,

On lun., 27 févr. 2023 at 22:14, Ludovic Courtès <ludo@gnu.org> wrote:

>> +(define-public calcmysky-qt5
>> +  (package
>> +    (inherit calcmysky)
>
> Rather:
>
>   (package/inherit calcmysky
>     (name "calcmysky-qt5")
>     …)

Out of curiosity, what is the rationale for this suggestion?

Cheers,
simon

Hi,

Simon Tournier <zimon.toutoune@gmail.com> skribis:

> On lun., 27 févr. 2023 at 22:14, Ludovic Courtès <ludo@gnu.org> wrote:
>
>>> +(define-public calcmysky-qt5
>>> +  (package
>>> +    (inherit calcmysky)
>>
>> Rather:
>>
>>   (package/inherit calcmysky
>>     (name "calcmysky-qt5")
>>     …)
>
> Out of curiosity, what is the rationale for this suggestion?

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.

Ludo’.

Hi,

On Fri, 3 Mar 2023 at 11:49, Ludovic Courtès <ludo@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'.

Cheers,
simon

Hi Simon,

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

> Hi,
>
> On Fri, 3 Mar 2023 at 11:49, Ludovic Courtès <ludo@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,

Hi Maxim,

On Fri, 3 Mar 2023 at 16:54, Maxim Cournoyer <maxim.cournoyer@gmail.com> wrote:

> 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).

Aahh, that makes sense. :-)  Thank you.

For instance, does it mean that

--8<---------------cut here---------------start------------->8---
(define-public gst-plugins-good-qt
  (package
    (inherit gst-plugins-good)
    (name "gst-plugins-good-qt")
    (inputs
     (modify-inputs (package-inputs gst-plugins-good)
       (prepend qtbase-5
                qtdeclarative-5
                qtwayland-5
                qtx11extras)))))
--8<---------------cut here---------------end--------------->8---

would be incorrect?  It should be 'package/inherit', right?

Cheers,
simon

Hi Simon,

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

> Hi Maxim,
>
> On Fri, 3 Mar 2023 at 16:54, Maxim Cournoyer <maxim.cournoyer@gmail.com> wrote:
>
>> 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).
>
> Aahh, that makes sense. :-)  Thank you.
>
> For instance, does it mean that
>
> (define-public gst-plugins-good-qt
>   (package
>     (inherit gst-plugins-good)
>     (name "gst-plugins-good-qt")
>     (inputs
>      (modify-inputs (package-inputs gst-plugins-good)
>        (prepend qtbase-5
>                 qtdeclarative-5
>                 qtwayland-5
>                 qtx11extras)))))
>
> would be incorrect?  It should be 'package/inherit', right?

It should be package/inherit yes, since they share the same source, thus
the same defects, thus should receive the same replacements/grafts (if
my preceding reasoning is correct :-)).

Hi all,

It was very insightful patch series I ever sent :-)
I hope I covered all recommendations in v3.

Thanks,
Oleg

On Sat, 4 Mar 2023, 03:32 Maxim Cournoyer, <maxim.cournoyer@gmail.com>
wrote:

> Hi Simon,
>
> Simon Tournier <zimon.toutoune@gmail.com> writes:
>
> > Hi Maxim,
> >
> > On Fri, 3 Mar 2023 at 16:54, Maxim Cournoyer <maxim.cournoyer@gmail.com>
> wrote:
> >
> >> 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).
> >
> > Aahh, that makes sense. :-)  Thank you.
> >
> > For instance, does it mean that
> >
> > (define-public gst-plugins-good-qt
> >   (package
> >     (inherit gst-plugins-good)
> >     (name "gst-plugins-good-qt")
> >     (inputs
> >      (modify-inputs (package-inputs gst-plugins-good)
> >        (prepend qtbase-5
> >                 qtdeclarative-5
> >                 qtwayland-5
> >                 qtx11extras)))))
> >
> > would be incorrect?  It should be 'package/inherit', right?
>
> It should be package/inherit yes, since they share the same source, thus
> the same defects, thus should receive the same replacements/grafts (if
> my preceding reasoning is correct :-)).
>
> --
> Thanks,
> Maxim
>