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

Previous Next

Full log

View this message in rfc822 format

From: Suhail Singh <suhailsingh247 <at> gmail.com>
To: Omar Bassam <omar.bassam88 <at> gmail.com>
Cc: 72925 <at> debbugs.gnu.org, Suhail Singh <suhailsingh247 <at> gmail.com>
Subject: [bug#72925] [PATCH v10] gnu: Add jpm.
Date: Sun, 06 Oct 2024 17:44:42 -0400

Omar Bassam <omar.bassam88 <at> gmail.com> writes:

>> 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? 

I am unable to get the exact message at the moment (due to non-technical
and unrelated reasons), but it was some missing header file.

As I mentioned in the quoted message above, however, what would be
better than propagating gcc, g++ etc would be to ensure that jpm passes
appropriate flags when invoking them.  Have you looked into that?

>>>> +    ;; 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?

Are you saying that when you test in a _non-pure_ shell where system
certificates are available, you observe failures?

In pure containers, the failure one observes if the user hasn't done
something to make certificates available is a commonly known occurrence.
See <https://issues.guix.gnu.org/70314> for patch to change this default
for networked containers.

Note that if you're not using a pure container, things should just work.
Please correct me if I am mistaken.

> I agree of giving the user the freedom to enable or disable this but I
> truly believe we need to provide sane defaults.

Bundling nss-certs would depart from the current conventions in Guix (as
I have recently come to understand).  For what it's worth, I also (now)
agree that it's not the place for _a package_ to make the determination
of which CAs to trust vs not.  However, since I don't have commit
authority, you are welcome to ignore my opinions.  My goal was simply to
demonstrate a working patch that didn't depart from current conventions.
I believe I did that.

Perhaps there is a discussion to be had, to revise said conventions
and/or to better understand the tradeoffs of said and related
conventions.  However, the guix-devel mailing list may be a better place
for such discussions, and it might help your cause of upstreaming jpm if
those discussions didn't block this patch.

>>> 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.

I invite you to join the discussion on guix-devel.  It's possible that
things that make sense to me, may not to you.

>>> 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?

It is the expected behaviour given my understanding of current packaging
practices in Guix.  I have nothing more to add beyond what I've already
said on this topic.

Regards,
-- 
Suhail

Previous Next

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