Re: bootstrapping on an older NetBSD without breaking existing installed pkgs?

[Carl Brewer <carl%bl.echidna.id.au@localhost>]

On 29/03/2017 11:27 PM, Greg Troxel wrote:
> Carl Brewer <carl%bl.echidna.id.au@localhost> writes:
>
> > I have an older NetBSD box that is due for upgrading, but it's not
> > going to happen for a few months yet, and it's got pkgsrc pkgs
> > installed on it that I would like to not break!
> > It's NetBSD 5.2.2 amd64
>
> NetBSD kernel/base binary compatibility is awesome, so things will
> basically just work if you binary upgrade the base system to NetBSD 6 or
> even 7 and keep your packages.  You need to overlay the new system
> without removing the libraries of the old system, but I am 99% sure the
> normal upgrade path does that.   The "INSTALL-NetBSD" script in
> pkgsrc/sysutils/etcmanage definitely does that, and that's what I've
> been using since 2005ish.
>
> I would take it to NetBSD 7, if that works, but would probably go to 6
> first.   For each upgrade hop, you should boot the kernel and validate
> that things work ok.   Everything should be ok except for firewalling
> (may need matching user/kernel) and X11.

Thank you Greg, this is long-term what I need to do, for sure.  The 
server doesn't run anything that's graphical, so the X11 stuff doesn't 
bother me :)

I did have a tentative stab at this not that long ago, but got lost in a 
mess of /etc changes that were taking too long for me to sort out at the 
time, so I just backed out and figured I'd try again later.  Now, is 
later, I guess!


> > I understand that in order to continue to use pkgsrc on this older
> > NetBSD it will need to be a bootstrapped pkgsrc rather than the
> > vanilla pkgsrc that I have used in the past. Mainly, AFAICT, it's
>
> I don't think that's true at all.   I have done "cvs up -r
> pkgrsrc-YYYYQN" and pkg_rolling-replace for many years on box, with
> exactly the user/kernel upgrades you are talking about.
>
> > issues with newer pkgsrc not liking the older NetBSD make.  bmake
> > seems to work, but there's some inconsistencies, and just making make
> > be a symlink to bmake is a little scary :)
>
> Yes, newer pkgsrc requires newish make.   So yes, you can add
> ~/bin/make -> /usr/pkg/bin/bmake
> and I have done that and it works.

I did too, but it does feel wrong!

> But really you should first upgrade the base system.  Then you won't
> have the old-make issue at all.

*nod*

> > Best procedure to use?  Short of upgrading everything to 7.1 that is
> > ... it's on the list!
>
> I would recommend that you put a 7.1 kernel in /netbsd and save the 5
> one in /netbsd.ok.  If that works ok, then install userland.   Then
> update pgksrc to 2017Q1 (not out yet, but it will be before you're
> done :).  I say 7 because 6 has an old compiler and old X11, and
> increasingly various things are breaking because of that.  We try to
> keep packages working on 6, but 7 is the main focus.
>
> Be careful about X11, if you need that.  7 is probably vastly better,
> but things are tricky.
>
> Then, either:
>
>   wait for binaries from bulk builds and learn pkgin.  make a list of
>   what you need.   Set aside your /usr/pkg and /var/db/pkg and start
>   over.  Install pkgin and then add what you need.
>
>   install pkg_rolling-replace.  Do "pkg_admin set rebuild=YES \*".  Run
>   "pkg_rolling-replace -uvk".   When you have issues, first try to
>   resolve them by removing packages that seem to be involved, keeping
>   notes about what you removed so you can build those at the end.   Keep
>   your tree free of stale working directories.
>
> The pkgin option is going to be far less trouble.   You'll learn more
> the other way :-)

In the past I've just run a cvs up on the source tree for pkgsrc every 
few weeks, run pkglint to see what's out of sync that I think was 
important, and then make && make update.  It's been 99.9% effective for 
a decade or more with my use pattern.

I'm not even sure of what pkgin or pkg_rolling-replace even are. Time to 
RTFM :)

Thank you,

Carl