tech-pkg archive

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

Re: scanner problem with packages depending on devel/gobject-introspection



Brook Milligan <brook%nmsu.edu@localhost> writes:

>> On Aug 1, 2018, at 8:10 AM, <maya%netbsd.org@localhost> <maya%netbsd.org@localhost> wrote:
>> 
>> Are you using a symlink'd /usr/pkg or similar, some glib2 tool follows
>> symlinks to get the absolute path and pkgsrc masks most of the
>> filesystem in compiler command line flags
>
> Yes, ${PREFIX} refers to a symlink.  I have now changed that to an absolute path and packages seem to be building fine.
>
> Would it make sense for bootstrap.sh or some part of mk/* to issue a
> warning about this requirement?  It seems easy to miss, because many
> packages can be built just fine with the symlink.  In my case I had
> several hundred packages already built successfully before running
> across the few that were confused by the symlink.  This made me think
> that the problem was something related to those particular packages,
> not something systemic about the pkgsrc setup.

Yes.  In my view we need to eiher

1) decide that it's a bug that packages lose when there is a symlink and
fix them or

2) change mk/ to fail hard with a message if there is a symlink issue

In the gobject-introspection case, what I've run into is not PREFIX
being a link, but having something like

 /n0/ANONCVS/pkgsrc

as the pkgsrc checkout with a link from /usr/pkgsrc, and building from
/usr/pkgsrc/category/foo.



At the very least it would be nice to have a BROKEN_IF_SRC_SYMLINK
variable for such pesky packages, and have the build fail for them, even
if not for others.


Home | Main Index | Thread Index | Old Index