unofficial mirror of guix-patches@gnu.org 
 help / color / mirror / code / Atom feed
From: Leo Prikler <leo.prikler@student.tugraz.at>
To: Thiago Jung Bauermann <bauermann@kolabnow.com>
Cc: 48443@debbugs.gnu.org
Subject: [bug#48443] [PATCH 1/2] gnu: Add texlive-libkpathsea.
Date: Wed, 14 Jul 2021 10:55:55 +0200	[thread overview]
Message-ID: <969b22ea43c5975192e99570d6ad79ebe26efd04.camel@student.tugraz.at> (raw)
In-Reply-To: <2781292.7Eo9FbQQbZ@popigai>

Hi Thiago,

Am Dienstag, den 13.07.2021, 22:48 -0300 schrieb Thiago Jung Bauermann:
> [...]
> 
> > On the part of inputs, sure, we could make libkpathsea smaller, but
> > I
> > have little experience with TeX Live and its build system, so I
> > decided
> > not to change its inputs for now.  If you have suggestions on how a
> > better closure could be achieved, please do bring them forth.
> 
> I was able to build the package with an empty input list. I compared
> a texlive-libkpathsea built with your unchanged patches and one with
> the empty input list and they are identical, except for the hash of
> the /gnu/store directory. Even the binary files, which I compared
> using hexdump. So my suggestion is to use an empty input list. :-)
Thanks for checking, v3 now uses an empty input list.

> > > In addition, if it were a separate package then texlive-bin could
> > > be
> > > made to use it, rather than shipping its own copy.
> > 
> > Perhaps that's an idea worth entertaining, but given the TeX Live
> > build
> > system I fear it's not an overwhelmingly practical one.
> 
> I can look into that separately, after your patches go in.
Fair enough.

> > > > +    (name "texlive-libkpathsea")
> > > > +    (source
> > > > +     (origin
> > > > +       (inherit (package-source texlive-bin))
> > > 
> > > Perhaps a ‘texlive-source-src’ variable analogous to ‘texlive-
> > > extra-
> > > src’ and ‘texlive-texmf-src’ would be useful?
> > 
> > I'm… not too sure on this one.  What would texlive-source-src
> > capture?
> > Just the upstream source?  Then we'd have to carefully apply all
> > the
> > fitting patches.  The same as (package-source texlive-bin)?  What's 
> > the
> > point then?
> 
> Yes, the point would be just to not duplicate the origin information.
> There would indeed be more work sorting out which security updates
> apply.
I'm not really convince that would help us.  texlive-libkpathsea still
needs to inherit from the origin so as to strip away all the others
sources.  So would every other part of texlive if built on its own. 
Perhaps one could instead do computed origins, but that increases
complexity rather than reducing it.  Therefore I'm not convinced
extracting this origin into its own variable is beneficial.

Regards,
Leo





  reply	other threads:[~2021-07-14  8:56 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-05-15 14:39 [bug#48443] [PATCH 0/2] Add libkpathsea Leo Prikler
2021-05-15 14:42 ` [bug#48443] [PATCH 1/2] gnu: Add texlive-libkpathsea Leo Prikler
2021-05-15 14:42   ` [bug#48443] [PATCH 2/2] gnu: evince: Build with libkpathsea Leo Prikler
2021-07-13  0:32   ` [bug#48443] [PATCH 1/2] gnu: Add texlive-libkpathsea Thiago Jung Bauermann via Guix-patches via
2021-07-13  7:58     ` Leo Prikler
2021-07-14  1:48       ` Thiago Jung Bauermann via Guix-patches via
2021-07-14  8:55         ` Leo Prikler [this message]
2021-07-14 16:23           ` Thiago Jung Bauermann via Guix-patches via
2021-07-15 11:44             ` bug#48443: " Leo Prikler
2021-07-13  7:56 ` [bug#48443] [PATCH v2 " Leo Prikler
2021-07-13  7:56   ` [bug#48443] [PATCH v2 2/2] gnu: evince: Build with libkpathsea Leo Prikler
2021-07-14  8:50 ` [bug#48443] [PATCH v3 1/2] gnu: Add texlive-libkpathsea Leo Prikler
2021-07-14  8:50   ` [bug#48443] [PATCH v3 2/2] gnu: evince: Build with libkpathsea Leo Prikler

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=969b22ea43c5975192e99570d6ad79ebe26efd04.camel@student.tugraz.at \
    --to=leo.prikler@student.tugraz.at \
    --cc=48443@debbugs.gnu.org \
    --cc=bauermann@kolabnow.com \
    /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).