GNU bug report logs - #72925
Adding JPM package for Janet

Previous Next

Full log

View this message in rfc822 format

From: Omar Bassam <omar.bassam88 <at> gmail.com>
To: Suhail Singh <suhailsingh247 <at> gmail.com>
Cc: 72925 <at> debbugs.gnu.org, Omar Bassam <omar.bassam88 <at> gmail.com>
Subject: [bug#72925] [PATCH v10] gnu: Add jpm.
Date: Sun, 06 Oct 2024 22:48:47 +0300

Hi Suhail,

Sorry, I have more questions.

> Omar Bassam <omar.bassam88 <at> gmail.com> writes:
>
>>> +  #:use-module (gnu packages certs)
>>
>> If we don't need nss-verts, do we still need this line?
>
> Good catch.  We don't need this.  Please remove in v11 when you send it.
>
>>> +    (propagated-inputs (list janet
>>> +                             ;; Lazily resolve the gcc-toolchain to avoid a
>>> +                             ;; circular dependency.
>>> +                             (module-ref (resolve-interface '(gnu packages
>>> +                                                              commencement))
>>> +                                         'gcc-toolchain)))
>>
>> Since we no longer need gcc-toolchain and we are just using gcc
>> directly, should we remove this module-ref expression and just add gcc
>> as a propagated input?
>
> What we need is _some_ mechanism to ensure that when jpm invokes gcc (or
> g++), the compiler is able to locate the appropriate header files.
>
> This should be doable without propagating any other inputs.  For example
> by ensuring that jpm sets appropriate environment variables (such as
> $CPATH , $C_INCLUDE_PATH , $CPLUS_INCLUDE_PATH etc.) or flags when
> invoking the compiler.  If so, that would be the preferred approach.  We
> only want to propagate those inputs that are strictly necessary.
>
> I do know that when I had tried to remove gcc-toolchain (without doing
> anything else) I encountered some errors during "jpm install -l sh" (in
> a pure shell).  However, I did not spend any effort in simplifying this,
> and I agree that we should try to.
>
> I look forward to seeing what you come up with in v11 :)
>

I gave tried replacing gcc-toolchain with gcc and both the "jpm install"
commands and the "jpm build" commands worked fine for me without any
issues. I didn't need to set up any C related environemnt variables.
What kind of error where you getting? 

>>> +    ;; NOTE: Below ensures that the user provides the CA certificates they
>>> +    ;; desire (as opposed to bundling `nss-certs' in propagated-inputs, which
>>> +    ;; isn't recommended) and when they do, that they are respected.
>>
>> Why isn't bundling nss-certs recommended?
>
> Doing so would deprive the user of the choice of which CAs to trust.
> I.e., if we were to bundle nss-certs we are taking an opinionated stance
> that the user agrees with Mozilla project's stance on these matters.
>

But how will the user know that they will need to install nss-certs in
the shell or that they need to setup these SSL environemnt variables?
I agree of giving the user the freedom to enable or disable this but I
truly believe we need to provide sane defaults.

>>> +    ;; FIXME: It's unclear why `search-paths', instead of
>>> +    ;; `native-search-paths', doesn't work.
>>
>> What are the difference between search-paths and
>> native-search-paths.
>
> These are documented in the info manual.  However, it's not clear to me
> _why_ native-search-paths is the right thing to use in this situation.
> I posted a message on guix-devel regarding this:
> <https://yhetil.org/guix-devel/87zfnipg4b.fsf <at> gmail.com/>.
>

OK, please let me know when you get to the bottom of this.

> The FIXME was simply an attempt to get the attention of others more
> knowledgable than me.  Use your discretion regd. whether to keep it or
> not.
>
>> And were you able to run the "jpm install" command without
>> nss-certs. Because, for me I was unable to do so.  When I added back
>> the nss-certs in propagated-inputs, it worked fine.
>
> That is expected behaviour.
>
> The way to test it, when in a pure container, would be by explicitly
> ensuring that certificates of trusted CAs are included in the profile.
> On way to do so would by adding nss-certs alongside jpm when invoking
> the shell.
>
> Relying on the package to provide nss-certs isn't desirable.  We simply
> want to ensure that when the certs are provided that the package _is
> able to use_ them.  This is what the native-search-paths line
> accomplishes.

I still don't understand why is it an expected behaviour if jpm by
default is expected to download packages mainly from github?


BRs,
Omar

Previous Next

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