pkgsrc-Users archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

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

On 10/25/18 11:13 AM, J. Lewis Muir wrote:

A binary bootstrap kit is available here, alongside my quarterly
snapshot builds:

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

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 (,



Home | Main Index | Thread Index | Old Index