From: MSavoritias <email@msavoritias.me>
To: me@tobias.gr, 73599@debbugs.gnu.org
Cc: ludo@gnu.org
Subject: bug#73599: packages from store paths don't propagate propagated-inputs
Date: Thu, 3 Oct 2024 11:07:04 +0300 [thread overview]
Message-ID: <eec68dbc-a058-4979-83b7-968164220867@msavoritias.me> (raw)
In-Reply-To: <2214f032-e5d5-4592-b05a-c7134cfcba62@msavoritias.me>
[-- Attachment #1: Type: text/plain, Size: 3142 bytes --]
MSavoritias kirjoitti 3.10.2024 klo 10.39:
>
>
> Tobias Geerinckx-Rice kirjoitti 2.10.2024 klo 21.22:
>> Hi [explicitly CC'ing Ludo', I hope that's OK],
>>
>> I don't think
>>
>> guix install $(guix build foo)
>>
>> is, or is expected to be, a supported way to install packages? Packages have more metadata attached to them than store items. I don't think that propagation is recorded in the Nix database. Nor do I think it should be just to support this hack.
>
> It actually is mentioned explicitly in the manual.
> https://guix.gnu.org/manual/devel/en/html_node/Invoking-guix-package.html
>
> from the link above:
>
> Alternatively, a package can directly specify a store file name such
> as /gnu/store/...-guile-3.0.7, as produced by, e.g., |guix build|.
>
> Sometimes packages have /propagated inputs/: these are dependencies
> that automatically get installed along with the required package (see
> |propagated-inputs| in |package| objects
> <https://guix.gnu.org/manual/devel/en/html_node/package-Reference.html#package_002dpropagated_002dinputs>,
> for information about propagated inputs in package definitions).
>
>
> There was an investigation yesterday at the xmpp room and that is how
> we discovered that the documentation has a bug. If we do not want to
> support it then this is just a documentation bug.
>
> Personally i could go either way. I already updated the project
> documentation I have to reflect not to do this
> https://codeberg.org/Guix_Bechamel/collective/wiki/Updating-Packages#testing-the-package-at-runtime
>
> MSavoritias
>
Sorry for the second reply just wanted to add some additional things here.
> Packages have more metadata attached to them than store items.
I was very surprised to discover this yesterday when somebody pointed it
out. The manual does not mention this in the store section. Is this
because what you want is a nar that is retrieved only when doing guix
export/import? at least that is my guess doing a search for metadata in
the guix manual.
Aside from that as a separate issue of concern
it was mentioned that the Gnu Guix channel has solved this by doing the
whole pre-inst-env architecture thing but i found little documentation
to go on in the manual aside from "keeping things separate". There is
also no mention of why it is needed, why these tools where picked, how
the architecture is arranged and interacts or what each tool actually
does. I tried to read the source files but there is not enough comments
to go on. I assume it is expected to know pathing, unix, autotools, bash
scripting among others but that is not mentioned and shouldn't be needed
imo.
Some clarifications of this would be nice but as I said these are out of
scope of this bug report probably.
Also some guide on the Guix manual by hopefully more knowledgeable
people on how you are supposed to test packages at runtime would be
nice. The guide only mentions to build packages but that doesn't make
sure that packages actually work. namely:
- po4a in the gnu channel of guix is atm broken. It misses gettext at
runtime.
- gajim doesn't show emojis
MSavoritias
[-- Attachment #2: Type: text/html, Size: 5287 bytes --]
next prev parent reply other threads:[~2024-10-03 9:47 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-10-02 14:46 bug#73599: packages from store paths don't propagate propagated-inputs MSavoritias
2024-10-02 18:22 ` Tobias Geerinckx-Rice via Bug reports for GNU Guix
2024-10-03 7:39 ` MSavoritias
2024-10-03 8:07 ` MSavoritias [this message]
2024-10-03 9:29 ` Tobias Geerinckx-Rice via Bug reports for GNU Guix
2024-10-03 9:34 ` MSavoritias
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://guix.gnu.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=eec68dbc-a058-4979-83b7-968164220867@msavoritias.me \
--to=email@msavoritias.me \
--cc=73599@debbugs.gnu.org \
--cc=ludo@gnu.org \
--cc=me@tobias.gr \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/guix.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).