pkgsrc-Users archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: none

Takahiro Kambe <> 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/ 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 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

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:


Attachment: pgpKAfbqGmVwh.pgp
Description: PGP signature

Home | Main Index | Thread Index | Old Index