Re: Detecting OS-provided software on Linux

[Iain Morgan <Iain.Morgan%nasa.gov@localhost>]

On Sat, Jan 25, 2014 at 20:53:59 +0000, Jonathan Perkin wrote:
> * 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

Thanks, doing this fixed the pax issue. Knowing about the
tools.linux.mik file should help with similar issues.

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

Indeed, tools.Linux.mk unconditionally sets TOOLS_PLATFROM.bash. The
version installed by pkgsrc is 4.2 whereas the system-provided one is
4.1.2,

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

Certainly, I'll post any additional changes once I've had a bit more
time to evaluate a more realistic set of software builds.

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

Thanks for the help!

-- 
Iain Morgan