On 2019-06-22 11:32, Brook Milligan wrote:
On Jun 22, 2019, at 9:21 AM, Jason Bacon <outpaddling%yahoo.com@localhost> wrote: What would be the advantage of providing non-pkgsrc package formats? Would it not suffice to provide standard binary pkgsrc packages for Linux, as I've been doing for quarterly snapshots on CentOS?Fair point. Perhaps a better solution than foreign packages is a broader effort to produce more such sets of binary pkgsrc packages and make them "official". And provide clearer documentation on using them and more standardized installation/bootstrapping, as you have also been working on. What resources are needed for NetBSD/pkgsrc to maintain officially blessed collections of binary packages made for a variety of other systems? Cheers, Brook
Easier initial deployment would also be a huge help.As perceived by end-users, competitors include MacPorts, Conda, Brew, etc. all of which are much easier for the layperson to install and start using.
Of the three mentioned, only MacPorts is really similar to pkgsrc in functionality, but the average scientist (my typical end-user) is unaware of important differences (like the ability to easily build from source with non-portable optimizations).
Pkgsrc is clearly the most capable package manager available for HPC when you factor in build flexibility, true portability, etc.
But in general, it's only accessible to true Unix nerds like us. The classic bootstrapping process is well beyond the average scientist who just wants to install ncbi-blast or gromacs as easily as possible and stay focused on their research.
Given the current pkgsrc user base, it's not clear whether the will exists to support less savvy users.?? My hope for pkgsrc in scientific computing is to push it forward far enough to ignite interest among the most tech-savvy scientists and reach a critical mass of maintainers that will get it rolling on its own.
I think this will require two things:1. Quick and easy deployment (binary bootstrap kits like the ones I provide are probably the best approach). 2. Filling in gaps among core scientific packages (e.g. BLAS family which Thomas Orgis has nearly finished, MPI, Flang, etc)
I've made a lot of progress on 1) with auto-pkgsrc-setup.?? 2) will take a while given the small number of contributors as of now.
There are a lot of reasons to be optimistic, though.?? Pkgsrc continues to grow rapidly in general and we have a solid set of development packages (compilers, interpreters, editors, etc.).
Whether or not it eventually snowballs as a science tool, it seems worth my time to keep nudging it forward.