Re: using pkg-config modules from host (Re: wip/py-numpy + blas)

[Greg Troxel <gdt%lexort.com@localhost>]

"Dr. Thomas Orgis" <thomas.orgis%uni-hamburg.de@localhost> writes:

> Please see my updated approach that uses
> mk/buildlink3/find-pkgconfig-files.mk.

Thanks, will have a look.

>> The right way is to have a package in pkgsrc for the thing that base
>> provides, and a builtin.mk.   As nros@ said we have lots of examples.
>
> Does that make sense for a package that is _only_ needed when it is
> present in the base system? I'm unsure about libtirpc, which is packaged.

I question "only needed when present".  Generally, pkgsrc expresses
depeendencies on packages.   If python is supposed to support NIS, then
it should express a dependency on the needed packages and it should be
there.

The current situation is:

  there's an implicit nis option in python.   It is not expressed in the
  options framework

  it is on if the base system has rpc/nis, and otherwise off.  This is
  look-at-headers trying to open-code what python does

  the PLIST is switched, but the "do NIS" vs "don't do NIS" is left to
  python, and the idea is that the yes/no in the PLIST var attempts to match

  there is no buildlinking of the extra library
  
I get it that the point of NIS is to be integrated into the base system
utilities, but pkgsrc supports things that could be like that but
aren't.

> I made python311 use both from the system if found … I might change
> that to only look for libnsl.pc and then set PLIST.nis=yes _and_ depend
> on libtirpc to trigger its builtin.mk.
>
> But I am unsure if packaging libnsl is the right thing to do. I
> wouldn't test the actual package, only the builtin case.

I agree this is hard to deal with.  I find that the nis file is included
in python on NetBSD 10.  But it only links with libc -- on NetBSD xdr
and yp are in libc.

>> I think it's a bug that random system libs that are not buildlinked are
>> visible.   For example a package that does not buildlink devel/zlib but
>> then picks up /usr/lib/libz is basically buggy.
>
> I forgot that you have lots of libs in /usr that you don't want to pick
> up in the general case. The whole point of buildlinking. Sorry. There's
> libc … and there's the kitchen sink. All at the same place:-/

Indeed - it is all very complicated and we are trying to minimize pain.
Some of that pain is from packages that if built with additional things
present change their behavior, vs only paying attention to what is
required.

Is this newly causing you problems?  I see the point, but I would expect
this to be longstanding.


I understand now that yp used to be glibc, but was pulled out so that it
could use TI-RPC for IPv6.   Why the in-libc RPC was not just upgraded
to do IPv6 is unclear to me.

I guess we can do one of

  - in python, just add something to link in the nsl pc file on
    GNU/Linux

  - in libtirpc, add base libnsl if linux and it exists.  This is icky
    because YP is not part of RPC.

  - in platform/Linux.mk, somehow add nsl as something to be available
    in the bl3 environment, since logically it's part of libc.

  - add a libnsl package that bl3's the linux bits on linux, and does
    nothing on systems known to have it in libc, and errors otherwise.
    bl3 this in for programs that use NIS

We can also

  - add an explicit nis option to python, and force off nis if not
    enabled.  This at least provides a cleaner place to put a
    workaround.


At this point what I am not clear on is: on GNU/Linux, does libnsl
depend on tirpc, and is there no longer rpc in libc either?