On Fri, Jan 24, 2014 at 01:23:20PM -0800, Iain Morgan wrote: |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. another reason that native packages may be preferable is to allow the hosts to use their own package distribution management - create the packages and whatever dependencies they need somewhere in a native format, add them to a central repo and then pull them down using existing tools to the rest of your fleet |Also, I would have expected that pkgsrc would still have built (and |installed) packages for any unsatisfied dependencies. true - I think someone else responded with builtin.mk hints which may help |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. this sounds to be a different problem, best addressed with something like the pkgsrc bulk package builder (pbulk?) in a chroot jail or a dedicated host/VM - that way the infrastructure takes care of building/nuking packages as it needs and you can just concentrate on the built packages it produces. whether it would be flexible enough to cater to different build options I'm not sure - I haven't used it in a while as the hosts I've been installing to have been too small to compile much effectively |> |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. given that we're doing something different in having pkgsrc packages installed in the native format we're concerned about conflicts in this area - we don't want to hose hosts where the automated patch management tools either replaces a pkgsrc-derived package with a native one or fails to upgrade the host completely because of some other reason so we're trying to keep the namespaces of stuff we've build obviously different, but I agree it would be nice to have ... |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. hmmmm ... tbh I've been looking at tools which so far have many fewer dependencies than that ... Regards, Malcolm -- Malcolm Herbert mjch%mjch.net@localhost
Attachment:
pgptImO7VX19g.pgp
Description: PGP signature