[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
- [bug#72925] [PATCH v10] gnu: Add jpm., Suhail Singh, 2024/10/05
- [bug#72925] [PATCH v10] gnu: Add jpm., Omar Bassam, 2024/10/06
- [bug#72925] [PATCH v10] gnu: Add jpm., Suhail Singh, 2024/10/06
- [bug#72925] [PATCH v10] gnu: Add jpm.,
Omar Bassam <=
- [bug#72925] [PATCH v10] gnu: Add jpm., Suhail Singh, 2024/10/06
- [bug#72925] [PATCH v10] gnu: Add jpm., Omar Bassam, 2024/10/07
- [bug#72925] [PATCH v10] gnu: Add jpm., Suhail Singh, 2024/10/07
- [bug#72925] [PATCH v10] gnu: Add jpm., Omar Bassam, 2024/10/07
- [bug#72925] [PATCH v10] gnu: Add jpm., Suhail Singh, 2024/10/07
- [bug#72925] [PATCH v10] gnu: Add jpm., Omar Bassam, 2024/10/07
- [bug#72925] [PATCH v10] gnu: Add jpm., Suhail Singh, 2024/10/07
- [bug#72925] [PATCH v10] gnu: Add jpm., Suhail Singh, 2024/10/07
- [bug#72925] [PATCH v10] gnu: Add jpm., Omar Bassam, 2024/10/08
- [bug#72925] [PATCH v10] gnu: Add jpm., Suhail Singh, 2024/10/08