unofficial mirror of guix-patches@gnu.org 
 help / color / mirror / code / Atom feed
From: Thiago Jung Bauermann via Guix-patches via <guix-patches@gnu.org>
To: Leo Prikler <leo.prikler@student.tugraz.at>
Cc: 48443@debbugs.gnu.org
Subject: [bug#48443] [PATCH 1/2] gnu: Add texlive-libkpathsea.
Date: Tue, 13 Jul 2021 22:48:37 -0300	[thread overview]
Message-ID: <2781292.7Eo9FbQQbZ@popigai> (raw)
In-Reply-To: <a612b229a3d608833fd735b3a0835776642779cd.camel@student.tugraz.at>

Hi Leo,

Thank you for your response and your new version of the patches.

Em terça-feira, 13 de julho de 2021, às 04:58:22 -03, Leo Prikler escreveu:
> 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.

My reasoning was that libkpathsea is just a small part of texlive-bin, so 
in principle a minority of texlive-bin security updates would apply to it. 
But you are right, there may well be some which would apply.

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

That is nice solution.

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

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

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

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

Thanks!

-- 
Thanks,
Thiago






  reply	other threads:[~2021-07-14  1:49 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 [this message]
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=2781292.7Eo9FbQQbZ@popigai \
    --to=guix-patches@gnu.org \
    --cc=48443@debbugs.gnu.org \
    --cc=bauermann@kolabnow.com \
    --cc=leo.prikler@student.tugraz.at \
    /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).