Re: properties for default version? (was bug#60200: Incompatibilities between gcc-toolchain and R packages)

[Simon Tournier]

Hi Ludo,

On mar., 17 janv. 2023 at 17:09, Ludovic Courtès <ludo@gnu.org> wrote:

>> For other cases, such issue is avoided by appending the suffix -next to
>> package name; as with ghc-next, python-numpy-next, emacs-next, etc.
>>
>> Personally, I find the -next trick useful because the package name
>> reflects that it is not the default.  However, it can be annoying to
>> update manifest files when this -next is becoming default.
>
> To me it’s mostly a packaging issue: I would expect ‘ocaml’ to be able
> to use ‘ocaml-ppxlib’.  If not, then it should indeed be ‘-next’.

Currently, yes it is a packaging issue.  And yes, the usual trick to fix
the issue is to append -next to the package name.  As I have tried to
explain in bug#60200 [1]. ;-)

About this -next, Lars’s answer is, quoting [2]:

        The -next suffix has the obvious disadvantage that
        specifications may become invalid as we move -next to the
        “regular” package. So maybe marking packages “default” like the
        attached patch does could improve the current situation. Not
        just for gcc, but also Haskell and Python come to mind.

Hence this discussion. :-)

The addition of a ’properties’ to make the difference between “current”
and “next” packages appears to be a cleaner fix than to append -next to
package name.

Consider the manifest:

    (specifications->manifest (list "ghc-next@9.2"))

and note that currently the Haskell compiler used by
haskell-build-system is ghc@8.10.7.

When this default is updated to an higher version of GHC, says version
9.4, then this manifest breaks because ghc-next@9.2 is renamed ghc@9.2;
the -next suffix is only applied to version higher than the one used by
the Haskell build system.


1: <http://issues.guix.gnu.org/msgid/86wn6nynp1.fsf@gmail.com>
2: <http://issues.guix.gnu.org/msgid/Y6LQs9+in964glaz@noor.fritz.box>


> I’m slightly reluctant because then you can have several packages that
> declare themselves as “default”, which looks weird.  Reasoning about why
> a given package was chosen would now involve more than version strings.

As similarly we can have several packages that declare themselves with
the same name and version. :-)

If we go for -next, then the two packages gcc-toolchain@{11,12} must be
renamed gcc-toolchain-next@{11,12} to be compliant and fixes bug#60200.


Why a given package was chosen as “default”?  Because the packages
marked as “default” are – if and only if several versions are publicly
declared – the ones used by the build-systems and also the ones with
many dependents as Numpy.  It avoids the -next dance.

Well, all in all this “default” property appears to me more elegant than
append -next to package name.

Cheers,
simon