* [bug#67660] [PATCH] gnu: texlive-xiften: Readd need input propagation @ 2023-12-06 14:01 Isaac van Bakel 2023-12-06 21:39 ` Nicolas Goaziou via Guix-patches via 0 siblings, 1 reply; 4+ messages in thread From: Isaac van Bakel @ 2023-12-06 14:01 UTC (permalink / raw) To: 67660; +Cc: Isaac van Bakel, Andreas Enge, Ricardo Wurmus * gnu/packages/tex.scm (texlive-xfithen)[propagated-inputs]: Readd propagation of `texlive-ifmtarg` to fix usage of package. Change-Id: I9e5e3cfa0fad3dc9fd3b4950eedf7443b254d2f1 --- This was removed as a "spurious" propagated input by the texlive-team-next changes, but in my usage it was not spurious and the package propagation is needed to use `xifthen` correctly. gnu/packages/tex.scm | 1 + 1 file changed, 1 insertion(+) diff --git a/gnu/packages/tex.scm b/gnu/packages/tex.scm index 0d76710daa..934cdb2a80 100644 --- a/gnu/packages/tex.scm +++ b/gnu/packages/tex.scm @@ -70883,6 +70883,7 @@ (define-public texlive-xifthen "0b33mlmnxsj5mi06v2w2zgamk51mgv1lxdr1cax8nkpn9g7n9axw"))) (outputs '("out" "doc")) (build-system texlive-build-system) + (propagated-inputs (list texlive-ifmtarg)) (home-page "https://ctan.org/pkg/xifthen") (synopsis "Extended conditional commands") (description base-commit: 8c294e43eb0b0ea61da7c0570872e0908f64c8ed -- 2.41.0 ^ permalink raw reply related [flat|nested] 4+ messages in thread
* [bug#67660] [PATCH] gnu: texlive-xiften: Readd need input propagation 2023-12-06 14:01 [bug#67660] [PATCH] gnu: texlive-xiften: Readd need input propagation Isaac van Bakel @ 2023-12-06 21:39 ` Nicolas Goaziou via Guix-patches via 2023-12-07 11:06 ` Isaac van Bakel 0 siblings, 1 reply; 4+ messages in thread From: Nicolas Goaziou via Guix-patches via @ 2023-12-06 21:39 UTC (permalink / raw) To: Isaac van Bakel; +Cc: 67660, Ricardo Wurmus, Andreas Enge Hello, Isaac van Bakel <isaac.vanbakel@inf.ethz.ch> writes: > * gnu/packages/tex.scm (texlive-xfithen)[propagated-inputs]: > Readd propagation of `texlive-ifmtarg` to fix usage of package. > > Change-Id: I9e5e3cfa0fad3dc9fd3b4950eedf7443b254d2f1 > --- > This was removed as a "spurious" propagated input by the > texlive-team-next changes, but in my usage it was not spurious and the > package propagation is needed to use `xifthen` correctly. > > gnu/packages/tex.scm | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/gnu/packages/tex.scm b/gnu/packages/tex.scm > index 0d76710daa..934cdb2a80 100644 > --- a/gnu/packages/tex.scm > +++ b/gnu/packages/tex.scm > @@ -70883,6 +70883,7 @@ (define-public texlive-xifthen > "0b33mlmnxsj5mi06v2w2zgamk51mgv1lxdr1cax8nkpn9g7n9axw"))) > (outputs '("out" "doc")) > (build-system texlive-build-system) > + (propagated-inputs (list texlive-ifmtarg)) This is a limitation in TeX Live, not Guix's, package definitions. The dependency is not reported in their "texlive.tlpdb" file. Note there are hundreds of such issues. We cannot realistically fix them manually ; for example this change would need to be tested every time Guix TeX packages are updated. I suggest to use collections of packages to avoid messing too much with individual dependencies, and possibly report those missing dependencies to the TeX Live project. Regards, -- Nicolas Goaziou ^ permalink raw reply [flat|nested] 4+ messages in thread
* [bug#67660] [PATCH] gnu: texlive-xiften: Readd need input propagation 2023-12-06 21:39 ` Nicolas Goaziou via Guix-patches via @ 2023-12-07 11:06 ` Isaac van Bakel 2023-12-07 11:52 ` Nicolas Goaziou via Guix-patches via 0 siblings, 1 reply; 4+ messages in thread From: Isaac van Bakel @ 2023-12-07 11:06 UTC (permalink / raw) To: Nicolas Goaziou; +Cc: 67660, Ricardo Wurmus, Andreas Enge Hello, On 2023/12/06 22:39, Nicolas Goaziou wrote: > This is a limitation in TeX Live, not Guix's, package definitions. The > dependency is not reported in their "texlive.tlpdb" file. > > Note there are hundreds of such issues. We cannot realistically fix them > manually ; for example this change would need to be tested every time > Guix TeX packages are updated. Is there no way to declare that a package auto-generated from TeX Live should be "patched" in some way (in this case, to include the dependency)? I'm aware that Nix does something like this for their various package sets. Perhaps this would be more sustainable than a fully-manual process. > I suggest to use collections of packages to avoid messing too much with > individual dependencies, and possibly report those missing dependencies > to the TeX Live project. Unfortunately this particular package only appears in an unopinionated collection in latexextra, which is very heavy for something that I have to put in my manifest just to fix a dependency issue. I'll look into getting the dependency registered on TL, but it's worth noting that they also don't want the responsibility of dependency tracking. They also don't recommend that package authors bother to put dependency information in their packages.[0] I'm conscious that this is a complex burden, but ideally *someone* would take it on so that the software works. Best, Isaac [0]: https://tug.org/texlive/pkgcontrib.html#deps ^ permalink raw reply [flat|nested] 4+ messages in thread
* [bug#67660] [PATCH] gnu: texlive-xiften: Readd need input propagation 2023-12-07 11:06 ` Isaac van Bakel @ 2023-12-07 11:52 ` Nicolas Goaziou via Guix-patches via 0 siblings, 0 replies; 4+ messages in thread From: Nicolas Goaziou via Guix-patches via @ 2023-12-07 11:52 UTC (permalink / raw) To: Isaac van Bakel; +Cc: 67660, Ricardo Wurmus, Andreas Enge Hello, Isaac van Bakel <isaac.vanbakel@inf.ethz.ch> writes: > On 2023/12/06 22:39, Nicolas Goaziou wrote: >> This is a limitation in TeX Live, not Guix's, package definitions. The >> dependency is not reported in their "texlive.tlpdb" file. >> >> Note there are hundreds of such issues. We cannot realistically fix them >> manually ; for example this change would need to be tested every time >> Guix TeX packages are updated. > > Is there no way to declare that a package auto-generated from TeX Live > should be "patched" in some way (in this case, to include the > dependency)? I'm aware that Nix does something like this for their > various package sets. Perhaps this would be more sustainable than > a fully-manual process. I don't know what Nix does. However, considering the sheer number of packages involved, I don't believe in the sustainability of anything even remotely manual. Now let's suppose we solve this. E.g., the importer greps through ".ins" or ".dtx" files to identify and declare a list of dependencies. Then we'll face another, greater, issue: it will be no longer possible to build TeX Live packages because of the dependencies loops we will have just introduced. Let me insist of the fact that I'm not talking about an hypothetical problem: I encountered it when I started to package the missing TeX Live bits a few months ago. If there's no solution, then there's no problem. ;) >> I suggest to use collections of packages to avoid messing too much with >> individual dependencies, and possibly report those missing dependencies >> to the TeX Live project. > > Unfortunately this particular package only appears in an unopinionated > collection in latexextra, which is very heavy for something that > I have to put in my manifest just to fix a dependency issue. > > I'll look into getting the dependency registered on TL, but it's worth > noting that they also don't want the responsibility of dependency > tracking. They also don't recommend that package authors bother to put > dependency information in their packages.[0] I'm conscious that this > is a complex burden, but ideally *someone* would take it on so that > the software works. The software works; the burden in on the user who wants to optimize their TeX Live installation. I think this is a reasonable, and common, expectation. I don't think the TeX Live installer takes a different approach. On a different context, compare a user installing a full blown DE, such as Gnome, to another one who picks a window manager, a file manager, etc., and needs to glue these parts together to make them behave as a coherent environment. As a data point, I have a 20-ish TeX Live packages from latexetra collection explicitly installed from my manifest as required dependencies. This list hardly ever increases or changes, so this is acceptable, at least for me. Sorry for being pessimistic. Maybe Someone™ will find an unexpected solution. Meanwhile, adding manually dependencies is, IMO, a no go. Regards, -- Nicolas Goaziou ^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2023-12-07 14:11 UTC | newest] Thread overview: 4+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2023-12-06 14:01 [bug#67660] [PATCH] gnu: texlive-xiften: Readd need input propagation Isaac van Bakel 2023-12-06 21:39 ` Nicolas Goaziou via Guix-patches via 2023-12-07 11:06 ` Isaac van Bakel 2023-12-07 11:52 ` Nicolas Goaziou via Guix-patches via
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).