Hello, commit 35089dca4053bf5888441d1648086cdadb6eb1e4 adds Qt to the xpdf package and removes most X libraries. The result is quite different and does not correspond to the synopsis "...based on the Motif toolkit" any more, and we get closer to more modern pdf readers such as evince or okular. On the other hand, I have been using xpdf as a "no frills" reader with an interface that had not changed forever, which I am missing now. Is this a change that became necessary with the update from 4.02 to 4.03 (that looks minor from the numbers!)? If no, I would like to suggest getting back to the previous inputs. If yes, I do not quite know what to do :) Andreas
Hello Andreas, On Fri, Feb 26, 2021 at 4:43 PM Andreas Enge <andreas@enge.fr> wrote: > commit 35089dca4053bf5888441d1648086cdadb6eb1e4 adds Qt to the xpdf package > and removes most X libraries. The result is quite different and does not > correspond to the synopsis "...based on the Motif toolkit" any more, and we > get closer to more modern pdf readers such as evince or okular. On the other > hand, I have been using xpdf as a "no frills" reader with an interface that > had not changed forever, which I am missing now. > > Is this a change that became necessary with the update from 4.02 to 4.03 > (that looks minor from the numbers!)? If no, I would like to suggest getting > back to the previous inputs. If yes, I do not quite know what to do :) Yes, it fails without it: CMake Warning at CMakeLists.txt:32 (message): Couldn't find Qt4 or Qt5 -- will not build xpdf. From the xpdf INSTALL file: * Make sure you have the following installed: - CMake 2.8.8 or newer - FreeType 2.0.5 or newer - Qt 4.8.x or 5.x (for xpdf only) - libpng (for pdftoppm and pdftohtml) - zlib (for pdftoppm and pdftohtml) If Qt isn't found, the GUI viewer (xpdf) won't be built, but the command line tools will still be built. This is also documented here: http://www.xpdfreader.com/download.html There may exist a cmake param to get the old bare xpdf, but I've not found it. -- Vincent Legoll
Hello Vincent,
thanks for your quick reply!
Am Fri, Feb 26, 2021 at 05:27:47PM +0100 schrieb Vincent Legoll:
> If Qt isn't found, the GUI viewer (xpdf) won't be built, but the
> command line tools will still be built.
Okay, I see. So they changed the program, and we should follow, although
I am not that happy about it - for a "more standard" pdf reader, I might
as well switch to evince or okular.
So I would like to ask a help-guix type question (but keep it here since
the context is already set up):
How can I personally keep the old variant?
Should I create a custom channel with xpdf@4.02? Or even xpdf@5 to have
a higher version number, but with the old 4.02 package code and source?
Or a manifest including some time-machine thing, or a personal package
transformation that compiles xpdf --with-source=...?
Andreas
In retrospect, I should probably have added a note in the commit
message that it would be a somewhat major change. With an
emphasis on the X -> QT migration.
On Fri, Feb 26, 2021 at 6:02 PM Andreas Enge <andreas@enge.fr> wrote:
> How can I personally keep the old variant?
> Should I create a custom channel with xpdf@4.02? Or even xpdf@5 to have
> a higher version number, but with the old 4.02 package code and source?
> Or a manifest including some time-machine thing, or a personal package
> transformation that compiles xpdf --with-source=...?
I don't really know the answer to this, but if you're copying the old code,
just name your "pinned" package "xpdf-4.02" so that it's not recognized
as "xpdf", and that should protect you from xpdf upgrades.
--
Vincent Legoll
> Should I create a custom channel with xpdf@4.02? Or even xpdf@5 to
> have
> a higher version number, but with the old 4.02 package code and
> source?
> Or a manifest including some time-machine thing, or a personal
> package
> transformation that compiles xpdf --with-source=...?
It's up to you, but some options are worse than others.
The easiest thing would be to inherit xpdf in your manifest and build
it from the old source. That should work pretty well and also update
xpdf if any of its dependencies change. You could also copy the entire
4.02 recipe to your history channel. Either way, make sure to refer to
it as xpdf@4.02 when installing from command-line or directly by
variable xpdf-4.02 when using it in a manifest. Do not create "higher"
versions for your own needs (unless they actually make sense, e.g.
you're packaging the yet unavailable version 4.04-alpha-we-got-back-
motif), that would conflict with Guix if a version 5 shipped, that had
Qt as an optional input with a Motif fallback.
Another would be to use inferiors from a manifest. Inferiors basically
work like time-machine, but expressed in terms of Scheme code.
A third option would be to generate an environment, that has xpdf@4.02
through time-machine and add that environment as a gcroot. Then you can invoke xpdf commands from that path and even source its etc/profile (inside your .bash_profile for instance) at startup.
Which one you grok the most is up to you, but it's definitely fun to
experiment 🙂
Regards,
Leo
Hi Andreas, On Fri, 26 Feb 2021 at 18:02, Andreas Enge <andreas@enge.fr> wrote: > How can I personally keep the old variant? I would go with inferior. <https://guix.gnu.org/manual/devel/en/guix.html#Inferiors> --8<---------------cut here---------------start------------->8--- (use-modules (guix inferior) (guix channels) (srfi srfi-1)) ;for 'first' (define channels ;; This is the old revision from which we want to ;; extract xpdf (list (channel (name 'guix) (url "https://git.savannah.gnu.org/git/guix.git") (commit "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx")))) (define inferior (inferior-for-channels channels)) (packages->manifest (list (first (lookup-inferior-packages inferior "xpdf")) (map specification->package (list "foo" "bar" …)))) --8<---------------cut here---------------end--------------->8--- where xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx is the last commit containing the version you like. Hope that helps, simon
Thank you, Vincent, Leo and Simon for all your suggestions! I note that they differ in whether xpdf gets recompiled when dependencies change (keeping a package around in a scheme file or channel) or not (using inferiors or a separate, not updated profile); probably both may have their advantages and disadvantages in practice. Andreas