Takahiro Kambe <taca%back-street.net@localhost> writes: > How we handling x11/Xaw3d v.s. x11/libXaw3d? > > * x11/Xaw3d and x11/libXaw3d are conflicted. > * Some packages need x11/Xaw3d and others do x11/libXaw3d. > * pkgsrc's framework mk/xaw.buildlink3.mk dose not know about > x11/libXaw3d at all. > > I wish this problem would be solved before branching pkgsrc-2015Q3. It's interesting that you mention this as I just had a similar problem; I wonder if something changed recently. I had a similar problem, building on netbsd-6 with X11_TYPE=modular. The root cause is that xaw.buildlink3.mk only sort of knows about modular vs native, combined with print/gv insisting on Xaw3d as the xaw type. xfig does the same thing. I have a fix, which I haven't sent or committed yet, which adds a modular/native switch around xaw3d, and in the modular case depends on libXaw3d. This makes gv build ok, and my system ends up with only libXaw3d. I will mail the patch tonight, but it's just replicating the modular if under standard in the 3d case. Normally we don't want to change mk/ during freeze, but if someone else on pmc says it should go in, that's ok with me. I think it's pretty low risk as not much uses 3d anyway in the bulk builds. Post freeze, we should probably find/remove direct inclusion of xaw*, or at least find/think. finddepends on x11/Xaw3d shows: graphics/xpaint/Makefile math/scilab/Makefile math/snns/Makefile multimedia/xawtv/Makefile sysutils/xfm/Makefile editors/emacs-snapshot/options.mk games/freeciv-client/options.mk
Attachment:
pgpKAfbqGmVwh.pgp
Description: PGP signature