Re: print/xpdf4
Greg Troxel <[email protected]>
| Newsgroups | gmane.os.netbsd.devel.packages |
|---|---|
| Message-ID | <[email protected]> |
pin <[email protected]> writes: > Today I've pushed an update to print/xpdf4 to wip, > https://mail-index.netbsd.org/pkgsrc-wip-changes/2026/02/23/msg035653.html > > While at it, I've moved the build to use Qt6 instead of Qt5. > > I've asked wiz@ to check it builds on his system as well and it passed the test. > > Anything against merging this update into pkgsrc proper now or, should the branching happen first? I was really not following what you were saying but having figured out my confusion it may help someone. print/xpdf (version 3) is a very lean pdf viewer that can work on small and moderate hardware. It does not use Qt at all. It is at version 3. print/xpdf4 currently uses qt5. Your proposed update is to print/xpdf4, a micro update and a switch to qt6. (I think print/xpdf should remain. You didn't propose removing it, so that's just a a comment.) My overall take on Qt (besides that it is enormous and thus not suitable for software that needs to run everywhere :-) is qt5 is no longer maintained and it's a bug for any package to still be on qt5. Many upstreams are not quite ready for qt6. E.g. qgis is soonish going to release 4.0 which can/should use qt6, while 3.44.x is qt5 only. pkgsrc qt6 is not 100% baked (said from working on qgis 4) but it's quite close and I think it's reasonable to use it in almost all cases. (That's not meant as criticism; it was an enormous effort to get all of qt6 working and it's very impressive what good shape it is in.) If this package builds and works with qt6, I think it's totally fine to simply update it. I don't see any reason to wait until post branch. If there are troubles we can add an option to use qt5 instead, but if there aren't troubles then it's better not to make it more complicated. I built wip/xpdf4 on NetBSD 10 amd64. It started up and worked fine. Longer term I don't see qt5 being dropped from pkgsrc for a long time. But I think that by the end of 2026 probably most programs will not use it and a typical system won't need to build/install it. Not relevant to your decision, just another random comment.