Building binary package off of remote binary set

["J. Lewis Muir" <jlmuir%imca-cat.org@localhost>]

Hello, all!

In

  https://mail-index.netbsd.org/pkgsrc-users/2018/11/01/msg027591.html

jperkin@ wrote:

  We are now offering our binary package sets for illumos in a rolling
  trunk release model.  These packages will be built from the latest
  pkgsrc every night and available for update through pkgin.

  [snip]

  As well as offering new and updated packages daily, this will avoid
  users having to perform cross-branch upgrades every quarter.  Another
  benefit will be for users who are helping the pkgsrc community provide
  patches and updates, as they will be able to provision a trunk
  pkgbuild image and develop their changes easily against pkgsrc trunk.

It sure would be nice to have a way to use Joyent (or TNF or other)
binary packages but be able to build private packages off of that.  In
other words, it would be great to not have to build locally all the
packages that Joyent (or TNF or other) has already built just because I
want to build some packages that are private.

The model I've been using is to run a limited pbulk build.  But the
problem with this is that invariably I end up needing to install
something new that I have not built in that limited set, and so I have
to wait a long time (e.g., 15+ minutes) for the new thing to build so I
can install it.  And that's just if it actually built successfully.  If
it failed, then I'm trying to figure out why it failed.  This is serious
rabbit-holing and incompatible with actually getting things done at
$WORK.

I've asked about building private packages off of a remote binary set
before in

  https://mail-index.netbsd.org/pkgsrc-users/2016/10/05/msg023830.html

and in that thread, joerg@ said that the problem with doing this is that
it almost always prevents having consistent packages.  My understanding
of the issue is that even if I don't change any package build options,
I could be building from a pkgsrc source tree that is not the same as
the one the binary packages were built from, and this alone is enough to
lose the guarantee of consistent packages.  Correct?

If yes, is this the same reason why bacon@ wrote in

  https://mail-index.netbsd.org/pkgsrc-users/2018/10/24/msg027580.html

that he's providing the exact pkgsrc source tree that was used to build
the set in his binary bootstrap kit?

If yes, would it work for Joyent's (or TNF's or other's) binary package
building infrastructure to indicate what repo snapshot it built the
binary package set from (e.g., create a tag or store the snapshot hash
in a file)?

Now that I've written all that, I think there's still a possible issue
if older versions of packages are not retained:

1. I update my local repo to the snapshot that was used to build the
   remote binary set.

2. I begin building my private package and it pulls in one dependency
   from the remote binary set.

3. The remote binary package building infrastructure completes a new
   binary package set build and atomically updates the files and the
   repo snapshot hash (e.g., tag or entry in a file).

4. My private package build pulls in a second package dependency from
   the remote binary set, but the version of the package that was there
   no longer exists, and the new version is inconsistent with the first
   dependency that has already been pulled down.

I suppose this could be solved by having the notion of a binary set
version, but maybe that in itself is already too much work for the
possible gain.  Is this ever likely to work, or should I just give up on
the idea for good?

What do others do for the scenario I described of having a limited
binary set and then needing a new package that's not in that set?

Thanks!

Lewis