Other packages depend on pari (libpari), like Macaulay2, and en up pulling in the entire texlive stack. Quite a significant runtime footprint. Please reconsider the existing Requires: tetex-xdvi dependancy Options include 1. drop the Requires, is it really required? (If so, please document such in the specfile) 2. create a standalone pari-libs subpkg 3. some other great idea I couldn't think of
I'd appreciate the creation of a standalone pari-libs subpkg; I'm converting perl-Math-Pari to use the system pari library rather than building its own copy, and the result is this: # yum install perl-Math-Pari-2.010802-1.fc12.x86_64.rpm Loaded plugins: refresh-packagekit Setting up Install Process ... --> Finished Dependency Resolution Dependencies Resolved ===================================================================================== Package Arch Version Repository Size ===================================================================================== Installing: perl-Math-Pari x86_64 2.010802-1.fc12 /perl-Math-Pari-2.010802-1.fc12.x86_64 869 k Installing for dependencies: Xaw3d x86_64 1.5E-14.fc11 fedora-dvd 170 k kpathsea x86_64 2007-42.fc11 fedora 118 k pari x86_64 2.3.4-2.fc11 fedora 1.4 M t1lib x86_64 5.1.2-3.fc11 fedora 214 k texlive x86_64 2007-42.fc11 fedora 2.2 M texlive-dvips x86_64 2007-42.fc11 fedora 200 k texlive-texmf noarch 2007-28.fc11 fedora 3.5 M texlive-texmf-dvips noarch 2007-28.fc11 fedora 392 k texlive-texmf-errata noarch 2007-6.fc11 fedora 4.8 k texlive-texmf-errata-dvips noarch 2007-6.fc11 fedora 4.9 k texlive-texmf-errata-fonts noarch 2007-6.fc11 fedora 5.0 k texlive-texmf-fonts noarch 2007-28.fc11 fedora 57 M xdvik x86_64 22.84.14-6.fc11 updates 735 k Transaction Summary ===================================================================================== Install 14 Package(s) Upgrade 0 Package(s) Total size: 66 M Total download size: 66 M Is this ok [y/N]: n Exiting on user Command Complete! Putting the library in a subpackage would save about 65M here.
*** Bug 579929 has been marked as a duplicate of this bug. ***
Gérard, can you please add a comment here to indicate that you're still involved with Fedora? I can't find any activity from you (bugzilla, CVS, devel list) in the last six months are there are many open tickets assigned to you: Bug # Status Component Reported Last comment from you 451092 ON_QA plt-scheme 2008-06-12 2008-06-23 472614 ASSIGNED plt-scheme 2008-11-21 None 475112 ASSIGNED ffcall 2008-12-07 2009-03-04 477464 NEW TeXmacs 2008-12-20 None 491012 NEW pl 2009-03-18 None 511303 ASSIGNED clisp 2009-07-14 2009-08-08 511362 ASSIGNED smarteiffel 2009-07-14 None 518335 NEW oorexx 2009-08-19 None 518895 NEW plt-scheme 2009-08-23 None 520971 NEW ocaml 2009-09-02 None 524130 NEW audacity 2009-09-17 None 529805 NEW unison227 2009-10-20 None 530565 NEW pari 2009-10-23 None 531422 NEW drscheme 2009-10-28 None 539047 ASSIGNED ucblogo 2009-11-19 None 539088 ASSIGNED clisp 2009-11-19 None 539154 ASSIGNED wings 2009-11-19 None 546766 NEW audacity 2009-12-11 None 548218 NEW gauche 2009-12-16 None 549405 NEW scons 2009-12-21 None 552596 NEW audacity 2010-01-05 None 554269 NEW audacity 2010-01-11 None 555455 NEW curry 2010-01-14 None 555499 NEW bigloo 2010-01-14 None 562615 NEW audacity 2010-02-07 None 562707 NEW qcad 2010-02-07 None 563981 NEW q 2010-02-11 None 564760 NEW gtkglarea2 2010-02-13 None 564772 NEW gtklp 2010-02-13 None 564848 NEW sweep 2010-02-13 None 567000 NEW sweep 2010-02-20 None 569041 NEW clisp 2010-02-27 None 570346 NEW audacity 2010-03-03 None 570456 NEW qcad 2010-03-04 None 571008 NEW audacity 2010-03-06 None 571160 NEW sweep 2010-03-07 None 572388 NEW audacity 2010-03-10 None 573489 NEW audacity 2010-03-14 None 575034 NEW TeXmacs 2010-03-19 None 577297 NEW audacity 2010-03-26 None 578647 NEW audacity 2010-03-31 None I'm now attempting to contact you as per the non-responsive maintainer policy: https://fedoraproject.org/wiki/Policy_for_nonresponsive_package_maintainers
(In reply to comment #3) > Gérard, can you please add a comment here to indicate that you're still > involved with Fedora? I can't find any activity from you (bugzilla, CVS, devel > list) in the last six months are there are many open tickets assigned to you: > > Bug # Status Component Reported Last comment from you > > I'm now attempting to contact you as per the non-responsive maintainer policy: > https://fedoraproject.org/wiki/Policy_for_nonresponsive_package_maintainers Now 3 weeks are passed, can we orphan those packages? I need scons 1.3 badly.
I had a response to a private email from Gérard on 25th April, though nothing since then. It seems he's still around, but busy. Have you applied in pkgdb for co-maintainership of the package(s) you're interested in? I'd also suggest writing directly to Gérard stating what you'd like to do.
My proposal(s) are already in comment #1, given any positive feedback on my suggestions, and I'd be happy to work to implement them (as a provenpackager).
make that the initial comment I mean.
I'd be happy with a package split creating a pari-libs package, as mentioned in Comment #1. I don't see any downside to that approach.
(In reply to comment #5) > I had a response to a private email from Gérard on 25th April, though nothing > since then. It seems he's still around, but busy. Have you applied in pkgdb for > co-maintainership of the package(s) you're interested in? I'd also suggest > writing directly to Gérard stating what you'd like to do. I'd be glad to co-maintain scons since it's a quite small package and easy to maintain, I'll update it to the latest version and some new features for it(e.g. rpm macros). One problem is gemi own some popular packages that is important to Fedora e.g. audacity, TeXmacs,ocaml, will it be better to ask him to send an emain to devel maillist and find some co-maintainers or let all other provenpackagers feel free to commit his packages?
Anyone can contact with gemi? I got no response after sending a mail to him.
I can't really see any reason why pari-2.3.4-2.fc11 has a Requires: tetex-xdvi. That RPM contains a single .so, and some files in /usr/share/doc. Where's this dependency? I'm not sure about the suggestion of putting the library in a subpackage. Without the library, there are just some doc files. None of the doc files appear to be tetex files.
my guess is that xdvi is called when calling pari documentation callback or the like.
(In reply to comment #12) > my guess is that xdvi is called when calling pari documentation callback or the > like. That's what gemi said in the package review: https://bugzilla.redhat.com/show_bug.cgi?id=169703#c2
(In reply to comment #13) > (In reply to comment #12) > > my guess is that xdvi is called when calling pari documentation callback or the > > like. > > That's what gemi said in the package review: > https://bugzilla.redhat.com/show_bug.cgi?id=169703#c2 The gp binary referenced in the package review is installed by pari-gp package. Which, curiously, does not have a Requires: tetex-dvi. The "Requires: tetex-dvi" should be in the pari-gp rpm, not the pari rpm.
I think that the gphelp call is part of the pari api. From reading the code, I'd say that xdvi is called from gphelp, set in doc/gphelp.in. But gphelp is not called from gp but from the pari library. At least the gphelp path is setup in paricfg.h which is generated during the Configure, and then used in src/language/default.c which is in the pari library. Maybe you could do a strings on the .so to see if it is there. My opinion would be to change "xdvi" in doc/gphelp.in to xdgopen, and then depend on xdgopen, and on a virtual dependency that would mean 'dvi viewer'.
[mrsam@commodore ~]$ strings /usr/lib64/libpari-gmp.so.2.3.4 | grep gphelp /usr/bin/gphelp It's there, but: [mrsam@commodore ~]$ ls /usr/bin/gphelp ls: cannot access /usr/bin/gphelp: No such file or directory gphelp is in pari-gp, which I do NOT have installed. In theory, pari should really have Requires: pari-gp, and pari-gp should really have Requires: tetex-dvi. In order to remove this dependency from the pari package, here's what I think needs to be done: Drop Requires: tetex-dvi from the pari rpm. It's broken anyway. Audit all upstream dependencies on pari. Put Requires: pari-gp into any rpm that uses pari, and makes use of this API call. If the application does not make use of this API call, it has no dependency. perl-Math-Pari does not use this API call: [mrsam@commodore tmp]$ strings /usr/lib64/perl5/auto/Math/Pari/Pari.so | grep help cv, name, numargs = 1, help = NULL So, perl-Math-Pari does not have this dependency.
(In reply to comment #16) > [mrsam@commodore ~]$ strings /usr/lib64/libpari-gmp.so.2.3.4 | grep gphelp > /usr/bin/gphelp > gphelp is in pari-gp, which I do NOT have installed. In theory, pari should > really have Requires: pari-gp, and pari-gp should really have Requires: > tetex-dvi. Nope, in my opinion, gphelp should be in the main pari package (at least, that's how I would do it). > Drop Requires: tetex-dvi from the pari rpm. It's broken anyway. If it is broken, it should be fixed where it is broken, not where it is convenient. > Audit all upstream dependencies on pari. Put Requires: pari-gp into any rpm > that uses pari, and makes use of this API call. If the application does not > make use of this API call, it has no dependency. That looks cumbersome to me, and anyway a library isn't only there to be used by other rpms, but also by applications linked against the library, so it should be functional. There are other possibilities, besides what I propose above (use xdgopen and have a virtual requires for a dvi viewer). Like replacing the xdvi call in gphelp by a wrapper that calls xdvi or any other xdvi viewer if installed, and otherwise proposes to install it.
xdg-open should be used to open DVI files, not a hardcoded call to the obsolete xdvi.
(In reply to comment #18) > xdg-open should be used to open DVI files, not a hardcoded call to the obsolete > xdvi. I completly agree. My guess is that upstream choosed xdvi because they pass options when showing the refcard: $xdvi = $ENV{GPXDVI} || "xdvi"; $xdviref = $ENV{GPXDVIREF} || "$xdvi -paper 29.7x21cm"; $viewer = ($f =~ /refcard/)? $xdviref: $xdvi; Still, in that case I think that gphelp.in should be patched to read $xdvi = $ENV{GPXDVI} || "xdg-open"; $xdviref = $ENV{GPXDVIREF} || "$xdvi"; A dvi viewer is still needed as adependency, though.
Looks like the trick to have an xdvi viewer is to have a Requires: mimehandler(application/x-dvi) in addition to a Requires for xdg-open. It seems to be present in F11.
Created attachment 418356 [details] use xdg-open in gphelp
Created attachment 418357 [details] spec file patch to use xdg-open and require mimehandler(application/x-dvi)
After a bit more investigation, it seems that the help system is not really available in the API. Indeed, it isn't in the libpari documentation, and, although it is available in GP_DATA, as GP_DATA->help, unless I am wrong, this should not be touched by libpari users. So it should be safe to move the xdg-open and mimehandler(application/x-dvi) requires to pari-gp.
(In reply to comment #5) > I had a response to a private email from Gérard on 25th April, though nothing > since then. It seems he's still around, but busy. Have you applied in pkgdb for > co-maintainership of the package(s) you're interested in? I'd also suggest > writing directly to Gérard stating what you'd like to do. Hi Paul, Is there any response from Gérard? I send a private mail 2 weeks ago, but get no response from him. Regards, Chen Lei
Hi Gérard, Following this process: https://fedoraproject.org/wiki/Policy_for_nonresponsive_package_maintainers I request you for a response, thanks!
(In reply to comment #24) > (In reply to comment #5) > > I had a response to a private email from Gérard on 25th April, though nothing > > since then. It seems he's still around, but busy. Have you applied in pkgdb for > > co-maintainership of the package(s) you're interested in? I'd also suggest > > writing directly to Gérard stating what you'd like to do. > > Hi Paul, > > Is there any response from Gérard? I send a private mail 2 weeks ago, but get > no response from him. I've not heard from Gérard since his email on 25th April.
Fwiw, looks like rhel6 doesn't even have tetex-xdvi , so I'll be rebuilding pari dropping that dep.
pari-2.3.4-5.fc13 has been submitted as an update for Fedora 13. http://admin.fedoraproject.org/updates/pari-2.3.4-5.fc13
pari-2.3.4-5.fc13 has been pushed to the Fedora 13 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update pari'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/pari-2.3.4-5.fc13
pari-2.3.4-5.fc13 has been pushed to the Fedora 13 stable repository. If problems still persist, please make note of it in this bug report.