On Wed, Sep 21, 2022 at 7:00 AM Jens-Ulrik Petersen <peter...@redhat.com> wrote:
>
> On Fri, Sep 16, 2022 at 1:14 AM Stephen Gallagher <sgall...@redhat.com> wrote:
>>
>> As I'm implementing this, I'm realizing that it probably only makes
>> sense to have the default version of Node.js on each Fedora release
>> provide the unversioned-command. Otherwise it becomes really hard to
>> ensure that the RPM macros like %{nodejs_sitelib} refer to the correct
>> location. So I think I'll stick with "if you're packaging for Fedora,
>> it has to work on the default Node release *or* you must deal with
>> everything yourself if you need to run on a different runtime".
>
>
> Sounds reasonable (as a non-nodejs user:)
>
> For our Haskell ghc, the new ghcX.Y packages introduced since F36 have given
> a big improvement in flexibility in my opinion.
> The main Fedora ghc package provides /usr/bin/ghc by default, though the
> ghcX.Y packages do have an optional unversioned subpackage for it that
> conflicts with ghc.
> So users are normally expected just to use the default version or specify the
> wanted version, unless they really want to default to a newer (or older in
> the future) one instead.
OK, I just took a look at how Haskell is doing this. I may take a cue
from ghc-deps.sh and implement a similar approach. Thanks for the
idea!
_______________________________________________
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
