cvs commit: src/lib Makefile.inc src/lib/libatm Makefile src/lib/libautofs Makefile src/lib/libbegemot Makefile src/lib/libbluetooth Makefile src/lib/libbsm Makefile src/lib/libbz2 Makefile src/lib/libc_r Makefile src/lib/libcrypt ...

[John Baldwin]

On Friday 15 June 2007 06:33:21 pm Hartmut Brandt wrote:
> John Baldwin wrote:
> > On Sunday 20 May 2007 10:49:08 pm Daniel Eischen wrote:
> >> deischen    2007-05-21 02:49:08 UTC
> >>
> >>   FreeBSD src repository
> >>
> >>   Modified files:
> >>     lib/libautofs        Makefile 
> > 
> > This isn't connected to the build AFAICT.
> > 
> >>   Log:
> >>   Bump library versions in preparation for 7.0.
> >>   
> >>   Ok'd by:        kan
> > 
> > Was this bump supposed to be exhaustive?  The following libraries haven't 
been 
> > bumped relative to 6.x:
> > 
> > - libalias
> > - libbsnmp
> >   - all the snmp_*.so modules
> 
> I'm probably not up-to-date with the handling of version numbers, but I 
> would think that the snmp_*.so modules version numbers are meant to 
> reflect the API version that these modules use (which is implemented by 
> bsnmpd). This hasn't changed, so what would be the reason to bump that 
> number? Same for libbsnmp.

If they depend on libc.so then they could try to pull libc.so.6 into an 
existing binary using libc.so.7 (or vice versa).  Probably for snmp_* and 
bsnmpd this doesn't matter since folks are likely to use the bsnmpd that 
comes with the OS.  But we bumped all of this for 6.0, which is why I'm 
asking if the bump was supposed to be exhaustive like 6.0, or if it was 
intentionally only bumping a subset.  The fact that most of the ncurses 
libraries were bumped but not the two 'libncurses*' suggests that at least 
that case is a bug.

> harti
> 
> > - libdialog.so.5
> > - libgnuregex.so.3
> > - libhistory.so.6
> > - liblwres.so.10
> > - libncurses.so.6
> > - libncursesw.so.6
> >   - rest of ncurses was bumped
> > - libpam.so.3
> >   - all the pam_*.so modules
> > - libreadline.so.6
> > - libssh.so.3
> > 
> 
> 



-- 
John Baldwin