guix-patches
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[bug#72925] [PATCH v10] gnu: Add jpm.


From: Omar Bassam
Subject: [bug#72925] [PATCH v10] gnu: Add jpm.
Date: Sun, 06 Oct 2024 22:48:47 +0300
User-agent: Gnus/5.13 (Gnus v5.13)

Hi Suhail,

Sorry, I have more questions.

> Omar Bassam <omar.bassam88@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@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






reply via email to

[Prev in Thread] Current Thread [Next in Thread]