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: Tue, 13 Jul 2021 09:58:22 +0200 [thread overview]
Message-ID: <a612b229a3d608833fd735b3a0835776642779cd.camel@student.tugraz.at> (raw)
In-Reply-To: <7264704.8eCzXKmJsZ@popigai>
Hello Thiago,
Am Montag, den 12.07.2021, 21:32 -0300 schrieb Thiago Jung Bauermann:
> [...]
> > +(define-public texlive-libkpathsea
> > + (package/inherit texlive-bin
>
> According to a recent message from Ludo¹, ‘package/inherit’ is meant
> to be
> used in specific situations, and IIUC it doesn’t apply here:
>
> > It should also be (package (inherit …) …) rather than
> > (package/inherit …). The latter is only useful when defining
> > variants of a package (same version, same code) where the same
> > security updates would apply.
I'm a little confused here, as that is exactly the rationale I'm
applying. When texlive-bin gets grafted due to kpathsea, the graft
also applies to texlive-libkpathsea. Granted, there is a large room
for false positives, that would result in gratuitous grafts for
texlive-libkpathsea, but I prefer erring on the side of security rather
than graftlessness here.
> I also wonder whether inheriting from texlive-bin is the best option.
> One disadvantage is that it makes this package too sensitive to
> changes in texlive-bin. As an example, it doesn’t work anymore with
> the version in core-updates because in the branch, the ‘postint’
> phase has been renamed to ‘post-install’. Also, I assume many
> texlive-bin inputs aren’t needed for texlive-kpathsea, causing
> unnecessary work when building texlive-libkpathsea and packages
> depending on it such as evince.
The postinst thing was my mistake – instead of inheriting from
%standard-phases as I should, I naïvely inherited texlive-bin's phases
instead. It turns out, I actually don't need any of those (and if I
did they'd be trivially copyable).
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.
> 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.
> > + (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?
> > + (snippet
> > + `(begin
> > + ,(origin-snippet (package-source texlive-bin))
> > + (with-directory-excursion "texk"
> > + (let ((preserved-directories '("." ".." "kpathsea")))
> > + (for-each
> > + delete-file-recursively
> > + (scandir "."
> > + (lambda (file)
> > + (and (not (member file
> > preserved-directories)) + (eq?
> > 'directory
> > (stat:type (stat file))))))))))))) + (arguments
> > + (substitute-keyword-arguments (package-arguments texlive-bin)
> > + ((#:configure-flags flags)
> > + `(cons* "--disable-all-pkgs" "--enable-kpathsea"
> > + "--enable-shared" ,flags))
> > + ((#:phases phases)
> > + `(modify-phases ,phases
> > + (delete 'configure-ghostscript-executable)
> > + (delete 'use-code-for-new-poppler)
> > + (delete 'patch-dvisvgm-build-files)
> > + (delete 'disable-failing-test)
> > + (replace 'postint
> > + (lambda* (#:key inputs outputs #:allow-other-keys)
> > + (with-directory-excursion "texk/kpathsea"
> > + (invoke "make" "install"))))))))))
>
> If you decide to continue inheriting from texlive-bin, you’d also
> need to change the synopsis and description.
Fair enough, that's on me. I've sent a v2 applying some of your
suggestions. Please feel free to point out anything I've missed or you
noticed in addition to what's already discussed.
Regards,
Leo
next prev parent reply other threads:[~2021-07-13 7:59 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 [this message]
2021-07-14 1:48 ` Thiago Jung Bauermann via Guix-patches via
2021-07-14 8:55 ` Leo Prikler
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=a612b229a3d608833fd735b3a0835776642779cd.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).