NetBSD Problem Report #45335

From Ephaeton@gmx.net  Tue Sep  6 14:27:46 2011
Return-Path: <Ephaeton@gmx.net>
Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11])
	by www.NetBSD.org (Postfix) with ESMTP id D6B3F63C093
	for <gnats-bugs@gnats.NetBSD.org>; Tue,  6 Sep 2011 14:27:46 +0000 (UTC)
Message-Id: <20110906142735.988822C85@agamemnon.entropie.local>
Date: Tue,  6 Sep 2011 10:27:35 -0400 (EDT)
From: Ephaeton@gmx.net
Reply-To: Ephaeton@gmx.net
To: gnats-bugs@gnats.NetBSD.org
Subject: postinstall: obsolete libs: use distribution sets
X-Send-Pr-Version: 3.95

>Number:         45335
>Category:       install
>Synopsis:       postinstall: obsolete libs: use distribution sets
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    install-manager
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Tue Sep 06 14:30:01 +0000 2011
>Last-Modified:  Tue Oct 08 11:50:00 +0000 2013
>Originator:     Martin S. Weber
>Release:        NetBSD 5.1_STABLE
>Organization:

>Environment:


System: NetBSD agamemnon.entropie.local 5.1_STABLE NetBSD 5.1_STABLE (AGAMEMNON5) #1: Sat Jul 16 16:22:03 EDT 2011 root@agamemnon.entropie.local:/space/obj/sys/arch/i386/compile/AGAMEMNON5 i386
Architecture: i386
Machine: i386
>Description:
	Please fix postinstall to use the distribution sets to determine
	obsolete files (especially libraries!!!) instead of nuking older
	minor/teeny versions.

	Why is that a problem?

	Do the following:

	1 install a release
	2 try a -current (run postinstall during installation)
	e run into a problem in -current
	3 go back down to a release (run postinstall during installation).
	pi your release now is unusable.

	How so? Basically the newest version survives, so if you have a
	new libc or libm (both of which is true currently on -current
	vs. release), the following happens:

	1 version old of lib x gets installed
	2 version new > old of lib x gets installed. postinstall nukes version old
	3 version old < new of lib x gets installed. postinstall STILL nukes version old
	pi the userland of release is linked against old, not new. All your binaries
	   fail. You curse and reach unhealthy blood pressure levels.

	Imho this could be fixed by looking at the libraries, looking which
	ones are mentioned in the distribution sets, and nuke the other ones.
	this would result in:

	1 version old of lib x gets installed
	2 version new of lib x gets installed. only new is in the distribution sets. old gets nuked
	3 version old gets installed. Only old is in the distribution sets. new gets nuked
	pi happyness, joy, unicorns everywhere

>How-To-Repeat:
	See description, 1,2,e,3,pi.
>Fix:
	No patch, sorry. 

>Audit-Trail:
From: "Martin S. Weber" <Ephaeton@gmx.net>
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: install/45335: postinstall: obsolete libs: use distribution sets
Date: Tue, 6 Sep 2011 11:03:02 -0400

 Btw, I think this is also the reason for install/34794 from 2006.

 Regards,
 -Martin

From: "Martin S. Weber" <Ephaeton@gmx.net>
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: install/45335: postinstall: obsolete libs: use distribution sets
Date: Wed, 29 Feb 2012 20:24:58 -0500

 Wouldn't it be nice to have this fixed in the NetBSD-6 distribution? You are
 talking about major lib bumps for NetBSD-7, so this is another catastrophe
 waiting to happen to anybody who will have NetBSD-6 installed, try -current
 to evaluate a bugfix, hardware driver, software feature or whatever and then
 decides to go back to the latest release...

 IMO, for NetBSD controlled directories (i.e. /lib, /usr/lib) deleting 
 everything which isn't in the distribution's mtrees should be fine, shouldn't
 it? Thus mtree -r for the specific library directories could be a fine and
 workable fix for the postinstall 'obsolete library' fix step.

 Regards,
 -Martin

From: Martin Husemann <martin@duskware.de>
To: gnats-bugs@NetBSD.org
Cc: Ephaeton@gmx.net
Subject: Re: install/45335: postinstall: obsolete libs: use distribution sets
Date: Thu, 1 Mar 2012 10:11:46 +0100

 On Thu, Mar 01, 2012 at 01:30:05AM +0000, Martin S. Weber wrote:
 >  IMO, for NetBSD controlled directories (i.e. /lib, /usr/lib) deleting 
 >  everything which isn't in the distribution's mtrees should be fine, shouldn't
 >  it?

 You need to leave around, for each shared library, for each major
 present the lib with the highest minor.

 Old static libs can just go away, IMHO.

 You are only talking about updates via sysinst from official (i.e. well
 tested) distribution media, I suppose? You certainly do not want to do
 this kind of cleanup on -current when updating from source.

 Martin

From: "Martin S. Weber" <Ephaeton@gmx.net>
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: install/45335: postinstall: obsolete libs: use distribution sets
Date: Thu, 1 Mar 2012 09:47:01 -0500

 On Thu, Mar 01, 2012 at 10:11:46AM +0100, Martin Husemann wrote:
 > On Thu, Mar 01, 2012 at 01:30:05AM +0000, Martin S. Weber wrote:
 > >  IMO, for NetBSD controlled directories (i.e. /lib, /usr/lib) deleting 
 > >  everything which isn't in the distribution's mtrees should be fine, shouldn't
 > >  it?
 > 
 > You need to leave around, for each shared library, for each major
 > present the lib with the highest minor.

 See the example I gave in the original PR. I hosed my release system
 by trying out a feature in -current to aid in PR solving. Then I went
 back to release as -current was unstable for me at the time, had
 postinstall run and deleted the wrong libraries. Why? Because for
 each shared library, for each major present, the lib with the highest
 minor was kept. NOT the one that was needed in the distribution due
 to the own distribution mtrees. Actually we do have the mtree files
 according to the sets; why would you try and guess to know better?
 The REAL dependencies are recorded already, so let's use them.


 > 
 > Old static libs can just go away, IMHO.

 Yes, if "old" = "no longer needed for the version that just was
 installed", not if "old" = "the one with the lower version number".
 See original PR and above for the kind of breakage that ensues if
 you opt for the latter.

 > 
 > You are only talking about updates via sysinst from official (i.e. well
 > tested) distribution media, I suppose? You certainly do not want to do
 > this kind of cleanup on -current when updating from source.

 Sure, why not?

 -Martin

From: David Holland <dholland-bugs@netbsd.org>
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: install/45335: postinstall: obsolete libs: use distribution sets
Date: Mon, 7 Oct 2013 05:24:15 +0000

 On Thu, Mar 01, 2012 at 09:15:05AM +0000, Martin Husemann wrote:
  >> IMO, for NetBSD controlled directories (i.e. /lib, /usr/lib)
  >> deleting everything which isn't in the distribution's mtrees
  >> should be fine, shouldn't it?
  >  
  >  You need to leave around, for each shared library, for each major
  >  present the lib with the highest minor.

 The problem is that if you try to revert from a version that has
 libfoo.so.5.10 to a version that has libfoo.so.5.5, you'll end up
 retaining libfoo.so.5.10 and it might not work. (In the case of libc,
 for example, a -current libc and a -6 kernel definitely won't work
 together.)

 ISTM that this is a real concern.

 -- 
 David A. Holland
 dholland@netbsd.org

From: phaeton@
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: install/45335: postinstall: obsolete libs: use distribution sets
Date: Tue, 8 Oct 2013 12:33:09 +0200

 On Mon, Oct 07, 2013 at 05:25:01AM +0000, David Holland wrote:
 > The following reply was made to PR install/45335; it has been noted by GNATS.
 > 
 > From: David Holland <dholland-bugs@netbsd.org>
 > To: gnats-bugs@NetBSD.org
 > Cc: 
 > Subject: Re: install/45335: postinstall: obsolete libs: use distribution sets
 > Date: Mon, 7 Oct 2013 05:24:15 +0000
 > 
 >  On Thu, Mar 01, 2012 at 09:15:05AM +0000, Martin Husemann wrote:
 >   >> IMO, for NetBSD controlled directories (i.e. /lib, /usr/lib)
 >   >> deleting everything which isn't in the distribution's mtrees
 >   >> should be fine, shouldn't it?
 >   >  
 >   >  You need to leave around, for each shared library, for each major
 >   >  present the lib with the highest minor.
 >  
 >  The problem is that if you try to revert from a version that has
 >  libfoo.so.5.10 to a version that has libfoo.so.5.5, you'll end up
 >  retaining libfoo.so.5.10 and it might not work. (In the case of libc,
 >  for example, a -current libc and a -6 kernel definitely won't work
 >  together.)
 >  
 >  ISTM that this is a real concern.

 ISTM, too. try a higher version of NetBSD, find there's a problem, downgrade,
 boom. Which is why I suggested at some point looking at the mtree sets for
 the distribution under the directories that are under NetBSD's control, in
 contrast to leaving the libs with the highest number lying around. And yes,
 I've shot myself in the foot doing that.

 Regards,
 -Martin

>Unformatted:

Home	PR Database Search