Re: building foreign packages with pkgsrc

[Brook Milligan <brook%nmsu.edu@localhost>]

> On Jun 22, 2019, at 3:33 PM, Joerg Sonnenberger <joerg%bec.de@localhost> wrote:
> 
>> How complicated would it be to support other formats using this framework?
> 
> The primary issue is the impedance mismatch between pkgsrc and other
> systems.

OK, so it seems that this is a significant challenge.  However, I think one way forward would be to not map dependencies onto the foreign packages, but rather use pkgsrc dependencies.  After all, all the pkgsrc packages have correct dependencies, right?  If we are making a full set of foreign packages from pkgsrc, then our dependencies should be just fine.  I'm not sure a mix-and-match approach between pkgsrc and some foreign system makes much sense.

Nevertheless, that may not be a productive way forward.  Instead, it may be better to do the following:

- create and maintain more repositories of native pkgsrc packages targeting different systems

- create and maintain binary releases of the pkgsrc tools, e.g., pkg_add, pkgin, etc. for different systems

- have a simplified "idiot's guide" to installing/managing binary packages with pkgsrc

- have a simplified (well documented) process for installing pkgsrc on a system

- make it easier to integrate pkgsrc into HPC systems, which all seem to run with modules; this requires documentation for that use case and an easy way to make module files for a set of installed packages

I think those steps would cater to the following use cases that have been identified:

- non-savvy user "just wants a package": quickly install the appropriate binary pkg_add tool (or similar) and install the binary package from one of our new repositories

- slightly-savvy user wants to build packages: quickly install pkgsrc and use pkg_chk (or similar) to build stuff

- HPC admin team: same as either of previous two (depending on desire to compile source) but also quickly build appropriate module files

- hard core pkgsrc users: this is all of us I suppose, who seem to be happy with the status quo but might benefit from, for example, simpler installation scripts to track branches or current

- others?

Does this capture the ideas adequately?

Cheers,
Brook