Re: Detecting OS-provided software on Linux

[Jonathan Perkin <jperkin%joyent.com@localhost>]

* On 2014-01-24 at 21:23 GMT, Iain Morgan wrote:

> As a trivial example, I built lang/go using pkgsrc on an RHEL 6.5
> system. To satisfy dependencies, pkgsrc had to install pax, bash, and
> perl; all of which were already on the system and the names were
> comparable to what pkgsrc used.

So, these are all handled by the tools infrastructure.  We usually try
to find native versions of pax and bash and will use them if
available, perl we usually prefer from pkgsrc as it's rather more
complicated.

Taking them one at a time:

 - pax is due to it being missing from mk/tools/tools.Linux.mk, and so
   pkgsrc will always use the pkgsrc version as it has no knowledge of
   a possible builtin.  Due to the inconsistencies in Linux
   distributions, what we should add in that file is:

     .if exists(/bin/pax)
     TOOLS_PLATFORM.pax?=       /bin/pax
     .elif exists(/usr/bin/pax)
     TOOLS_PLATFORM.pax?=       /usr/bin/pax
     .endif

   You could try adding this, doing a 'bmake clean clean-depends' and
   trying again

 - bash is odd, as that is in the tools file for Linux and it is
   pretty much guaranteed that /bin/bash will exist on a Linux system,
   so I'm not sure why that's being pulled in.  I don't see any
   version checks where it would pull in the pkgsrc version if the
   builtin one is too old, so it would be interesting to debug this
   case.

 - to use the native perl, you can set

     TOOLS_PLATFORM.perl=  /path/to/perl 

   in your mk.conf and it will be used anywhere perl is required as a
   build tool.  It won't however be used if building any package which
   has a runtime requirement on perl, we don't support that.

Generally, you can use TOOLS_PLATFORM.x= /path/to/x in your mk.conf to
override what pkgsrc will use, but we'd like to integrate any fixes
such as pax to provide a better user experience by default.

> In another case, I built xlockmore and found that pkgsrc installed
> 107 packages to satisfy dependencies. I expect that the majority of
> those dependencies were already satisfied by native packages, and at
> least some of them matched the names used by pkgsrc.

When building from source directly onto the target machine in
question, you will get a lot of build dependencies installed.  The way
to avoid this is to build separately in a chroot or a different
machine and then install binary packages on each machine which
requires them.

There are various ways of achieving this, and we can provide further
information on them if necessary.

Regards,

-- 
Jonathan Perkin  -  Joyent, Inc.  -  www.joyent.com