Re: New -current binary bootstrap kit for RHEL/CentOS 7

[Jason Bacon <outpaddling%yahoo.com@localhost>]

On 10/25/18 11:13 AM, J. Lewis Muir wrote:
> > A binary bootstrap kit is available here, alongside my quarterly
> > snapshot builds:
> >
> >      http://mirror1.hpc.uwm.edu/pkgsrc/bootstrap-kits/
> >
> > Download, verify the sha512, and unpack with
> What's the point of verifying the checksum when it's hosted on the same
> server as the .tgz file and the checksum is not hosted on HTTPS?
Oops: The server does support SSL - that should read https:
> >      tar -C / -zxvf pkgsrc-RHEL7-gcc-6.0-usr-pkg.tgz
> >
> > The kit includes /usr/pkg and /usr/pkgsrc.
> >
> > The source tree is a git repository containing a snapshot of -current.
> >
> > The reason for this is to ensure that the source tree is in sync
> > with the binary packages at all times.  I update and rerun
> > pbulk frequently, but irregularly, and have run into issues with
> > dependency versions when mixing binary packages and
> > source builds.
> >
> > With this simple system, I update the public git repo to exactly
> > match the source tree used by pbulk at the same time I publish a new
> > set of packages.
> That's interesting.  So, this is how you let your users use your binary
> packages if they exist, but at the same time be able to build their own
> packages for things that don't exist in your binary repository?
>
> But you're providing a full set of pkgsrc binary packages, so really
> this would be just for private pkgsrc packages that your users build and
> use?
>
> And I presume you don't support a user building a package with
> non-default options when that package already exists in your binary
> repository since that would likely risk dependency problems?
Two reasons I generally build from source:

1. wip packages.   I have often hit dependency issues here if my source 
tree is newer than the binary package set, usually due to bl3 version 
requirements.  Old package + something newer required in the dependency 
tree = a real mess.

2. Build an optimized, non-portable binary, e.g. -march=native, which 
can be significantly faster than the binary packages.  This is sometimes 
very important in scientific computing, where one study could easily use 
a million core-hours.
> > To upgrade and keep everything in sync, just do the following:
> >
> > pkgin upgrade
> > cd /usr/pkgsrc
> > git pull
> That's cool.
>
> Are your binary packages signed?  If so, how does a user set up
> signature validation in pkgin?  If not, do you offer the packages for
> download over HTTPS?  Otherwise, there's no way for a user to have
> confidence about the integrity of any package from your repository.
I have not added signing yet (just a matter of very scarce time and 
priorities), but as I mentioned above, you can use https on both my 
servers (mirror1.hpc.uwm.edu, mirror2.hpc.uwm.edu).

Cheers,

    JB