| Summary: | sci-electronics/geda-docs: documentation installed outside /usr/share/doc/${PF} | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Diego Elio Pettenò (RETIRED) <flameeyes> |
| Component: | New packages | Assignee: | The Soldering-Iron Brotherhood <sci-electronics> |
| Status: | RESOLVED WONTFIX | ||
| Severity: | minor | CC: | |
| Priority: | High | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Bug Depends on: | 285470 | ||
| Bug Blocks: | |||
| Attachments: | patch to geda-docs-1.4.3.ebuild | ||
Created attachment 212105 [details, diff]
patch to geda-docs-1.4.3.ebuild
This patch fixes the installation directory of the docs.
Thanks. package geda-doc is the documentation for the gEDA tools, mainly the schematics editor gschem. gschem's Help Menu can show the documentation -- if we put it in geda-docs-1.4.3 instead of the default geda-docs gschems access may fail. Please note: We have gEDA 1.6 in the tree -- I regards older versions as obsolete. Best regards Stefan Salewski (In reply to comment #2) > Thanks. > package geda-doc is the documentation for the gEDA tools, mainly the schematics > editor gschem. gschem's Help Menu can show the documentation -- if we put it in > geda-docs-1.4.3 instead of the default geda-docs gschems access may fail. I think that the better approach is patch the other packages to find the doc in the new location. > Please note: We have gEDA 1.6 in the tree -- I regards older versions as > obsolete. It's strange consider a version newer than the version on the stable branch as obsolete. You need keep in mind that geda 1.6 is on the unstable branch. I think that all ebuilds on portage tree needs work fine. :) Rafael G. Martins wrote: >I think that the better approach is patch the other packages to find the doc in >the new location. This may be true. >It's strange consider a version newer than the version on the stable branch as >obsolete. You need keep in mind that geda 1.6 is on the unstable branch. I >think that all ebuilds on portage tree needs work fine. :) Please note: Denis is currently the only official gentoo developer for sci-electronics, he is very busy and currently there exist some other problems with him too. When I did the work for gEDA 1.4.3-r1 early this year that was my first ebuild -- I did my best, and Denis revised it carefully. Now geda developers have decided to bundle all gaf packages into one tar file to support parallel build. This makes the ebuild simpler, and gEDA/gaf 1.6 really works fine. Maybe we should try to stabilize 1.6.0 soon. (Early next year 1.6.1 is planned by gEDA developers.) I can not put time into old 1.4.3, sorry, to much other work, and I will try to support Denis with upcomming 1.6.1 and PCB20100xyz. Maybe with other gEDA related tools like gerbv and xgsch2pcb also again. Maybe Denis (or his recruit) will work on 1.4.3 -- I do not know. Best regards Stefan (In reply to comment #4) > Please note: Denis is currently the only official gentoo developer for > sci-electronics, he is very busy and currently there exist some other problems > with him too. When I did the work for gEDA 1.4.3-r1 early this year that was my > first ebuild -- I did my best, and Denis revised it carefully. Now geda > developers have decided to bundle all gaf packages into one tar file to support > parallel build. This makes the ebuild simpler, and gEDA/gaf 1.6 really works > fine. Maybe we should try to stabilize 1.6.0 soon. (Early next year 1.6.1 is > planned by gEDA developers.) I can not put time into old 1.4.3, sorry, to much > other work, and I will try to support Denis with upcomming 1.6.1 and > PCB20100xyz. Maybe with other gEDA related tools like gerbv and xgsch2pcb also > again. Maybe Denis (or his recruit) will work on 1.4.3 -- I do not know. I know almost all these problems. BTW, I'm his recruit :) About the patch that I suggested, I can work in this when I have some free time. My point is: if some ebuild doesn't work as expected and no one can or want to fix it, this ebuild should be removed from the tree. :( (In reply to comment #5) > > again. Maybe Denis (or his recruit) will work on 1.4.3 -- I do not know. > > I know almost all these problems. BTW, I'm his recruit :) > > About the patch that I suggested, I can work in this when I have some free > time. > > My point is: if some ebuild doesn't work as expected and no one can or want to > fix it, this ebuild should be removed from the tree. :( > Oh sorry -- I think Denis told me your name, but I did not remembered it. I hope you will become an official gentoo developer soon. Maybe I will become one next year too, but I still have to learn much... I agree with you, ebuilds in the official tree should have very high quality and of course should work fine. But I regard the name of the docs directory as a minor problem, of course it would be fine if you can fix it. (In reply to comment #6) > Oh sorry -- I think Denis told me your name, but I did not remembered it. > I hope you will become an official gentoo developer soon. Maybe I will become > one next year too, but I still have to learn much... I'm glad to hear that you are planning to be a gentoo developer too. Your work is great! :) > I agree with you, ebuilds in the official tree should have very high quality > and of course should work fine. But I regard the name of the docs directory as > a minor problem, of course it would be fine if you can fix it. > That's ok. Thanks. The problem is fixed in geda-1.6.1 (thanks Stefan). As soon as 1.6.1 is completly stable (bug # 285470) these bug can be closed. geda-docs-1.4.3 was removed from tree, so closing the bug. |
You're getting this bug because the package in summary installs its documentation (or at least part of it) outside the usual /usr/share/doc/${PF} directory. First, please keep in mind that this bug might not be noticeable for -r0 ebuilds, but it might be for -r1 and later, since if the ebuild has same name and version of the package, for -r0 it might correspond properly. To fix this, if the package uses autotools, recent version (autoconf 2.61+) have two ./configure switches: --docdir and --htmldir to decide where to put the documentation. Older versions might require you override docdir/htmldir or other custom variables during make install. For non-autotooled build systems, good luck, since I cannot tell you how to achieve the proper results, the same holds true with totally broken buildsystems even when based on autotools. Thanks, Diego