From: John Darrington <john@darrington.wattle.id.au>
To: Andreas Enge <andreas@enge.fr>
Cc: guix-devel@gnu.org
Subject: Re: Texlive and native-inputs
Date: Wed, 29 Oct 2014 18:13:09 +0100 [thread overview]
Message-ID: <20141029171309.GA30858@jocasta.intra> (raw)
In-Reply-To: <20141029165958.GA4944@debian.eduroam.u-bordeaux.fr>
[-- Attachment #1: Type: text/plain, Size: 1926 bytes --]
On Wed, Oct 29, 2014 at 06:00:02PM +0100, Andreas Enge wrote:
Currently, texlive has a certain number of native inputs:
(native-inputs
`(("perl" ,perl)
("pkg-config" ,pkg-config)
("python" ,python-2) ; incompatible with Python 3 (print syntax)
("tcsh" ,tcsh)))
But I think these are not needed during build time, but to patch-shebang
scripts that are installed into the bin directory. So should they not be
normal inputs?
If they were "normal" inputs and you were cross compiling, then the packages which
are made available, would be those for the target system, not the native one. Hence
they could not run, and the build would break.
This is part of commit c4c4cc05979f2a2d0212963c5fe1b940d63a0958 which was
a mass-move from inputs to native-inputs. I wonder if these need to be
verified one by one by hand? How does one know without going through every
line of the build logs whether an interpreter is used during the build
or in installed scripts?
You are probably right - to be sure they should be manually checked. An
alternative would be to attempt cross building all the affected packages. That
said, I cannot envisage a scenario where a non-native pkg-config would be
needed. In the case of perl, python, etc I recall that previous discussions
concluded that if they are needed in installed scripts, then it should be up to the
user to install them.
Or what happens if both is the case?
In that case, the package would need to be declared as both an input and a native-input.
Did I misunderstand anything?
From your first paragraph, I think you did.
J'
--
PGP Public key ID: 1024D/2DE827B3
fingerprint = 8797 A26D 0854 2EAB 0285 A290 8A67 719C 2DE8 27B3
See http://sks-keyservers.net or any PGP keyserver for public key.
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
next prev parent reply other threads:[~2014-10-29 17:13 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-10-29 17:00 Texlive and native-inputs Andreas Enge
2014-10-29 17:13 ` John Darrington [this message]
2014-10-29 17:39 ` Andreas Enge
2014-10-29 17:52 ` John Darrington
2014-10-29 18:51 ` Andreas Enge
2014-10-29 19:55 ` John Darrington
2014-10-29 22:31 ` Andreas Enge
2014-10-30 7:53 ` John Darrington
2014-10-30 8:02 ` Andreas Enge
2014-10-30 9:24 ` John Darrington
2014-10-29 22:37 ` Ludovic Courtès
2014-10-29 22:29 ` Ludovic Courtès
2014-10-29 17:43 ` Andreas Enge
2014-10-29 18:03 ` John Darrington
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=20141029171309.GA30858@jocasta.intra \
--to=john@darrington.wattle.id.au \
--cc=andreas@enge.fr \
--cc=guix-devel@gnu.org \
/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).