Re: IGNORE_OSVERSION=yes -- can't install pkg

From: Chris H <bsd-lists_at_BSDforge.com>
Date: Mon, 07 May 2018 20:54:29 -0700
On Mon, 7 May 2018 09:56:16 +0200 "Baptiste Daroussin" <bapt_at_FreeBSD.org> said

> On Sat, May 05, 2018 at 10:47:36AM -0600, Ian Lepore wrote:
> > On Sat, 2018-05-05 at 08:26 -0700, Chris H wrote:
> > > On Fri, 04 May 2018 22:57:52 -0700 <bsd-lists_at_BSDforge.com> said
> > > 
> > > > 
> > > > I just setup a jail from a 12-CURRENT I built awhile ago. It has no
> > > > ports
> > > > tree. So I'm attempting
> > > > to install svnlite. issuing pkg search svnlite returns
> > > > The package management tool is not yet installed on your system.
> > > > Do you want to fetch and install it now? [y/N]: y
> > > > Bootstrapping pkg from pkg+http://pkg.FreeBSD.org/FreeBSD:12:amd64/
> > > > latest,
> > > > please wait...
> > > > Verifying signature with trusted certificate
> > > > pkg.freebsd.org.2013102301...
> > > > done
> > > > [12current.localhost] Installing pkg-1.10.5...
> > > > Newer FreeBSD version for package pkg:
> > > > To ignore this error set IGNORE_OSVERSION=yes
> > > > - package: 1200062
> > > > - running kernel: 1200054
> > > > Allow missmatch now?[Y/n]:
> > > > 
> > > > Umm, what? Should I ignore this error? If so, why is there an error
> > > > at all?
> > > > I answered no. Guess I won't be able to use pkg(8) on this jail(8).
> > > > :-(
> > > > 
> > > > --Chris
> > > OK the only reference[1] I can find regarding this, indicates that
> > > answering "Y"
> > > to Allow missmatch now? resulted in an ABI mismatch that caused
> > > pkg(8) to be
> > > unusable.
> > > This is on an older version of 12, so I don't have anything that
> > > might have
> > > appeared in UPDATING. I really need this jail to resolve accumulating
> > > pr(1)'s
> > > on ports(7) I maintain.
> > > 
> > > Thank you.
> > 
> > The difference between 1200062 and 1200054 isn't going to affect
> > anything except modules which are intimate with kernel internals, such
> > as video drivers or virtualbox type stuff.
Thanks, Ian. Glad to hear it.
> > 
> > IMO, this new version checking done by pkg(8) is just bad Bad BAD. The
> > only control you get is a knob that tells you to ignore any version
> > mismatch. There appears to be no option to get the historical worked-
> > really-well behavior of ignoring mismatches of the minor version for
> > people who track -current.
> > 
> 
> Except you devs are looking at it with a -CURRENT usage in mind.
> 
> Most of our users are running releases.
> 
> And you end up with en issue when let's say FreeBSD 10.0 is EOLed then the
> packages are now built on 10.1, if people continue running 10.0 because for
> instance they missed the notice about the 10.0 being EOL, they end up
> installing
> packages that may be broken: new libc symbols for example, new syscalls etc.
> 
> This check was one of the number 1 request over the last 3 years...
> For all people running -CURRENT they can add IGNORE_OSVERSION=yes.
> 
> More over, I received so many false bug report because actually developpers
> were
> reporting "pkg is broken!!!" because they run pkg upgrade on a current
> system
> that was 6+ month old or running pkg upgrade just after an ABI change that I
> consider this warning worth it.
> 
> The only thing I would accept considering here is an advice on how to make
> the
> tests more smooth for -CURRENT users. I consider an IGNORE_OSVERSION to be
> good
> enough.
> 
> I might change in next versions of pkg the runtime OSVERSION detection
> reading
> /bin/ls binary to be replaced by uname(1) to make it more friendly with
> incremental rebuild.
Thanks for the reply, Bapt!
I hear your point, and it seems reasonable. But I have a couple nits;
1) Adding IGNORE_OSVERSION=yes to make.conf(5) had no affect.
2) Would it be remotely possible for the error to be slightly more
informative?
As it stands, it appears that in order to use pkg(8) in this situation.
Ones *only* option is to answer Y. IMHO this seems wrong.

Thanks again!

--Chris
> 
> Bapt
Received on Tue May 08 2018 - 01:52:45 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:41:15 UTC