| Summary: | sci-mathematics/snns-4.2-r8.ebuild (update for Modular X) | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Ian Stakenvicius <ian> |
| Component: | New packages | Assignee: | Patrick Kursawe (RETIRED) <phosphan> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | jakub, sci |
| Priority: | High | ||
| Version: | 2006.0 | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Attachments: | snns-4.2-r8.ebuild proposed to comply better w/Xorg-7 | ||
Created attachment 90901 [details]
snns-4.2-r8.ebuild proposed to comply better w/Xorg-7
attached the snns-4.2-r8.ebuild proposed to comply better w/Xorg-7
Why do you think this is necessary? As far as I can tell they're all dependencies of libXaw3d on which snns depends. Please re-open if you still think something is missing. An additional question: Why do you think it is OK to replace libXaw3d in REDPEND by libXaw in DEPEND? I don't understand this. <snip> DEPEND="X? ( || ( virtual/x11 x11-proto/xproto ) ... ) </snip> Please, change the order there and preferably change virtual/x11 to <virtual/x11-7.0 too, as portage seems to have circular dep issues with the above (see Bug 133671). As for the rest, seems really redundant to stick any more deps there (looks like virtual/x11 related if portage missed then, which in turn might be related to the wrong order above.) Thanks for the hint, in CVS. THe libXaw DEPEND is there because SNNS wouldn't build for me without it (Xaw3D wasn't enough -- no idea why, i agree that it should have been). It doesn't replace Xaw3D, it's in adition. This was on the box that didn't have X11 installed yet when i (re)emerged SNNS. As for the rest, yes there are some duplicated dependencies there (ie, most of those libs are also required for x11-proto/xproto), however the SNNS code references these libs directly too (according to 'linking_libs.sh' and 'included_headers.sh' from the Moxular X Porting Howto), so wouldn't it be better to have them as deps for this package too, instead of assuming they'll be there because of being deps for another package? ==== include_headers.sh info: ==== Absolute headers: sys-libs/glibc-2.3.6-r4 x11-proto/xproto-7.0.5 x11-libs/libX11-1.0.1-r1 x11-libs/libXt-1.0.2 x11-libs/libXaw-1.0.2 sys-kernel/linux-headers-2.6.11-r2 ==== linking_libs.sh output: ===== Tracing libraries back to packages ... sys-libs/glibc-2.3.6-r4 x11-libs/libX11-1.0.1-r1 x11-libs/libICE-1.0.1 x11-libs/libSM-1.0.1 x11-libs/libXext-1.0.1 x11-libs/libXmu-1.0.2 x11-libs/libXt-1.0.2 ================================== ..so I guess I could've cleaned up the DEPEND/RDEPEND a bit more and move some things around.. xproto should be a build dep instead of being in RDEPEND i guess.. and you're right, going through the dep tree does include all of the above (with the exception of libXaw) in the RDEPEND of Xaw3d. So yeah, as long as it and its deps don't change there's no need to have them here as well. |
Since the original Modular-X update disappeared and didn't quite work anways, I propose the following addition, so that virtual/x11-7 doesn't get included on the xorg-x11-r7 upgrade. I've tested this on amd64 (with an existing Xorg-7 install) and on x86 with no Xorg installed at all (so snns brought in the libraries it needed) + x11-forwarding via ssh to provide the display. Here's the new DEPEND and RDEPENDs: RDEPEND="X? ( || ( ( x11-libs/libX11 x11-libs/libICE x11-libs/libSM x11-libs/libXext x11-libs/libXmu x11-libs/libXt x11-proto/xproto ) virtual/x11 ) x11-libs/Xaw3d ) >=sys-apps/sed-4 python? ( >=dev-lang/python-2.3 )" DEPEND="${RDEPEND} X? || ( x11-libs/libXaw virtual/x11 )" Completed attachment to follow.