[bug#48443] [PATCH 1/2] gnu: Add texlive-libkpathsea.

[Thiago Jung Bauermann via Guix-patches via <guix-patches@gnu.org>]

Hi Leo,

Em quarta-feira, 14 de julho de 2021, às 05:55:55 -03, Leo Prikler 
escreveu:
> 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.

Thanks! v3 looks great to me.
 
> > > > > +    (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.

Yes, that is true. In my previous message I was agreeing with you that the 
origin idea didn’t bring much benefit. Sorry for not being clear.

-- 
Thanks,
Thiago