Re: package upgrade strategy

[Robert Elz <kre%munnari.OZ.AU@localhost>]

    Date:        Thu, 28 Sep 2017 22:20:50 +0200 (CEST)
    From:        r0ller <r0ller%freemail.hu@localhost>
    Message-ID:  <Av5PyQ.4D3ebciagh4.L2U6p9zQZ2Xw2q4uL17%freemail.hu@localhost>


  | but I hoped that there's a way to avoid compiling relatively big programs
  | (like seamonkey) in a case when I just want to check something out [...]

There is - you can keep using the binary packages, for everything that
still exists in pkgsrc (and for which binary packages are available).
You just need to use the sources for midori (or any other package that
has been deleted) because there are no new binary packages being produced
for that.

For everything else you just do binary package upgrades, then when
everything is in place (which will have resulted in midori having
been deleted) you just compile your copy of that (using the old pkgsrc
directory for it) from sources.

As long as it continues to build, that should be easy enough.  Of
course, over time, that gets less and less likely, unless you are
upgrading it yourself.

If you want to protect it so you have a binary that will work like it
does now, regardless of anything else that happens, you should be able
to make that work, by setting up an entirely separate /usr/pkg tree (ie:
storing it someplace else) - get a version of pkgsrc that includes midori
(an older one than current) change the PKG_DBDIR and LOCALBASE / PREFIX,
and build just midori from source with those settings (which will also
build all of its dependencies, since in that tree, nothing will exist yet).

Once that's done, simply leave that tree alone forever, and never touch
it again.   It will remain completely independent of anything that is
normally done with pkgsrc, not influencing it at all.  In the regular
/usr/pkg you just keep doing binary pkg_add pkg_delete ... as desired
to install and delete packages you want to test.

kre

ps: "kids" is perfectly OK to use at least for this native English speaker.