[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: Detecting OS-provided software on Linux
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
> 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
> 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
Indeed, tools.Linux.mk unconditionally sets TOOLS_PLATFROM.bash. The
version installed by pkgsrc is 4.2 whereas the system-provided one is
> - 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.
> Jonathan Perkin - Joyent, Inc. - www.joyent.com
Thanks for the help!
Main Index |
Thread Index |