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