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



> On Aug 1, 2018, at 12:13 PM, Greg Troxel <gdt%lexort.com@localhost> wrote:
> 
> 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

Perhaps this thread will lead to a consensus on which option to take.  In my looking about gobject-introspection it was not entirely clear how to fix this in a non-invasive way, and I'm not sure about eagerness of upstream to deal with this.  Then again, the details of gnome are well beyond what I normally think about.

The second option, however, is something we can implement in pkgsrc.

> 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.

This is exactly what I did, except that in addition I had /usr/pkg be a symlink to elsewhere.  I'm not sure which was the culprit; your experience suggests the former.  However, all the buildlink files are pointing through the /usr/pkg symlink, which leads me to expect the latter.

> 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.

It seems like this is a fairly confusing issue, so I expect it better to handle pkgsrc-wide instead of per-package.

Cheers,
Brook




Home | Main Index | Thread Index | Old Index