Re: Detecting OS-provided software on Linux

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

On Thu, Jan 23, 2014 at 10:39:44 +1100, Malcolm Herbert wrote:
> On Wed, Jan 22, 2014 at 02:56:10PM -0800, Iain Morgan wrote:
> |Initial tests are promising, but I've noticed that pkgsrc does not
> |detect all the software that was installed by the native (RPM)
> |packaging system. The resultant duplication of software is inefficient
> |and undesirable; particularly as I will have multiple independent
> |software trees managed by separate pkgsrc instances.
> 
> how about doing it the other way - pkgsrc can be told to create native
> packages for at least Solaris and RedHat (iirc). With tweaking you may
> be able to make your OS package system be the one source of truth rather
> than split it up ... still don't know whether that would prompt pkgsrc
> to pick already-installed native packages over recompiling a pkgsrc one
> though ...

Hmm, I don't think that would really meet our needs. If we were just
dealing with a single system, and did not need to use environment
modules, then that strategy would probably work. Up till now, we have
simply been building software by hand and using environment modules to
enable users to choose which builds they want to use.

Also, I would have expected that pkgsrc would still have built (and
installed) packages for any unsatisfied dependencies.

I expect that some of the complications could be avoided if we used a
separate filesystem for our build process. In that case, pkgsrc could
build all the packages that it needs, but we would install (using tar)
only those packages that we really needed on the production filesystem.
Of course, that means providing our own mechanism to ensure that all of
the runtime dependencies are satisfied.

> 
> |What I would like, is some way to either export information from
> |a system's RPM database to pkgsrc, or some means for pkgsrc to
> |dynamically query the installed RPM's when checking dependencies. Is
> |there any easy way to do either of these?
> 
> I think the problem of namespaces is going to ruin your day here - none
> of the linux distros even get the same name for the identical package
> across the board and I can't really see how this could be achieved
> without a lot of work to maintain it ...

The differences in naming schemes between different Linux distributions
would certainly make a general solution more complicated. However, I'm
only dealing with two distributions. Also, the mechanism does not have
to be perfect. The names of some RPMs will vary from distro to distro,
and the names may not resemble those used by pkgsrc. Moreover, there may
not be a one-to-one mapping between a given Linux distro and pkgsrc.
However, there will still be a non-trivial subset of packages that have
a consistent name across different systems to make this worthwhile.

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. 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.
> 
> Regards,
> Malcolm
> 
> -- 
> Malcolm Herbert
> mjch%mjch.net@localhost



-- 
Iain Morgan