NetBSD-Bugs archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

PR/57581 CVS commit: [netbsd-10] src/distrib/sets/lists



The following reply was made to PR misc/57581; it has been noted by GNATS.

From: "Martin Husemann" <martin%netbsd.org@localhost>
To: gnats-bugs%gnats.NetBSD.org@localhost
Cc: 
Subject: PR/57581 CVS commit: [netbsd-10] src/distrib/sets/lists
Date: Tue, 5 Sep 2023 17:26:25 +0000

 Module Name:	src
 Committed By:	martin
 Date:		Tue Sep  5 17:26:24 UTC 2023
 
 Modified Files:
 	src/distrib/sets/lists/base [netbsd-10]: shl.mi
 	src/distrib/sets/lists/debug [netbsd-10]: shl.mi
 	src/distrib/sets/lists/xbase [netbsd-10]: shl.mi
 	src/distrib/sets/lists/xdebug [netbsd-10]: shl.mi
 
 Log Message:
 Pull up following revision(s) (requested by riastradh in ticket #348):
 
 	distrib/sets/lists/xbase/shl.mi: revision 1.103 (patch)
 	distrib/sets/lists/debug/shl.mi: revision 1.329 (patch)
 	distrib/sets/lists/xdebug/shl.mi: revision 1.69 (patch)
 	distrib/sets/lists/base/shl.mi: revision 1.969 (patch)
 
 lists: Remove bogus libfoo.so.N and libfoo.so.N.M obsolete entries.
 
 These must stay around so applications linked against them will still
 work after upgrade, even if libfoo.so now points to libfoo.so.(N+1)
 or libfoo.so.N.(M+1).
 
 Exceptions:
 - I'm willing to believe the rump modules have a different story so I
   left those obsolete entries alone.
 - libuv.so was never supposed to be exposed publicly anyway and never
   went out in a release.  (Maybe this information should be recorded
   somewhere?)
 - Same is probably true of lib{gmp,mpc,mpfr}.so, not sure of the
   history.  Maybe libg2c.so too, no idea what that is.
 - libisns.so was moved from /usr/lib to /lib, so it's legitimate for
   the debug data to live there too now.  (XXX Maybe we should have a
   separate marker for this.)
 - Libraries under /usr/tests are not used by normal applications, so
   they can safely be deleted when obsoleted.
 
 Note: The libfoo.so symlink for a library that has been deleted
 altogether, not just upgraded, can be obsoleted.  Loadable modules
 that applications aren't linked against can be obsoleted, even if
 some of them like npf ext_*.so or pam_*.so are formally versioned
 (for reasons unclear to me).
 
 Note: This means that incremental builds may complain about these
 .so.N and .so.N.M files in destdir (PR misc/57581), but it's much
 worse for an upgrade to break working applications.
 
 
 To generate a diff of this commit:
 cvs rdiff -u -r1.942.2.8 -r1.942.2.9 src/distrib/sets/lists/base/shl.mi
 cvs rdiff -u -r1.298.2.9 -r1.298.2.10 src/distrib/sets/lists/debug/shl.mi
 cvs rdiff -u -r1.102 -r1.102.2.1 src/distrib/sets/lists/xbase/shl.mi
 cvs rdiff -u -r1.68 -r1.68.2.1 src/distrib/sets/lists/xdebug/shl.mi
 
 Please note that diffs are not public domain; they are subject to the
 copyright notices on the relevant files.
 


Home | Main Index | Thread Index | Old Index