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

Previous Next

Full log

Message #127 received at 72925 <at> debbugs.gnu.org (full text, mbox):

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: Re: [PATCH v10] gnu: Add jpm.
Date: Mon, 07 Oct 2024 21:24:33 +0300

Suhail Singh <suhailsingh247 <at> gmail.com> writes:

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

I am not really an expert in compiling C programs so I'm not sure what
would be the best way to verify this? the "jpm build" command ran fine
for me and I don't have any of those C*PATH environment variables set.

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

Yes, it did fail initially even in a non-pure non-container shell. I had
to manually set the SSL_CERT_DIR environment variable to /etc/ssl/certs
(I'm on Ubuntu). I did not need to set the SSL_CERT_FILE variable.
Is it possible to set a default value for that environment variable?
I'm not sure though if the /etc/ssl/certs/ is a standard among all Linux
distros or just Ubuntu.

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

Thank you, I'm relatively very new to Guix, so I definitely need to read 
involved more about those discussions.

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

BRs,
Omar

Previous Next

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