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

Re: Radical idea, test backwards compatibility instead of recompile



On Sat, Oct 07, 2000 at 04:55:41PM -0400, Greg Stark wrote:
> Ben Collins <bcollins@debian.org> writes:
> 
> > Theoretically perfect. IOW, let's not assume anything is wrong with it.
> > Test the upgrades, compile against it, and report bugs. As far as I'm
> > concerned, it's starting with a clean slate, and only through testing is
> > it going to be know for sure....for instance, being in unstable and people
> > using it.
> 
> But everyone has recompiled against libc 2.1.94 now so we've lost the
> opportunity to test the backwards compatibility of libc6. That's my only
> comment here.

Install it on potato, that should do the trick.

> > Ulrich's own words (paraphrased) "this release has less known bugs than
> > 2.1.3", which says a lot coming from the person that did most of the
> > development.
> > 
> > > What I'm suggesting is that we learn a different lesson from the libdb
> > > breakage. The general reaction has been to run around recompiling packages to
> > > work around a broken bit of backwards compatibility. Now that we've determined
> > > that it was the backwards compatibility that failed I'm suggesting we revert
> > > those mistaken unnecessary recompiles and actually test that glibc is
> > > backwards compatible. Instead of going on faith that it's "perfect".
> > 
> > If you recompile them, they will be the same as they are now. The libdb in
> > 2.1.94-3 is *runtime* only, meaning you cannot compile against it.
> > Downgrade to the potato version and see if that still works (2.1.94-4 will
> > have the conflicts removed, just for that testing).
> 
> Exactly the same? Then the shlibs file is wrong:
> 
> libm 6 libc6 (>= 2.1.94)
> libc 6 libc6 (>= 2.1.94)
> /lib/ld-linux 2 libc6 (>= 2.1.94)
> ld-linux 2 libc6 (>= 2.1.94)
> libdl 2 libc6 (>= 2.1.94)
> libutil 1 libc6 (>= 2.1.94)
> libresolv 2 libc6 (>= 2.1.94)
> libnss_files 2 libc6 (>= 2.1.94)
> libnss_dns 2 libc6 (>= 2.1.94)
> libnss_compat 2 libc6 (>= 2.1.94)
> libnss_nis 2 libc6 (>= 2.1.94)
> libnss_nisplus 2 libc6 (>= 2.1.94)
> libnss_ldap 2 libc6 (>= 2.1.94)
> libnss_hesiod 2 libc6 (>= 2.1.94)
> libnsl 1 libc6 (>= 2.1.94)
> libdb 3 libc6 (>= 2.1.94)
> libdb1 2 libc6 (>= 2.1.94)
> libcrypt 1 libc6 (>= 2.1.94)
> libBrokenLocale 1 libc6 (>= 2.1.94)
> librt 1 libc6 (>= 2.1.94)
> libpthread 0 libc6 (>= 2.1.94)
> libthread_db 1 libc6 (>= 2.1.94)

I don't see your point here. The fact that libdb and libdb1 show up here
is only for the sake of policy. In -4 it will just be "libdb 3" (no dep).

-- 
 -----------=======-=-======-=========-----------=====------------=-=------
/  Ben Collins  --  ...on that fantastic voyage...  --  Debian GNU/Linux   \
`  bcollins@debian.org  --  bcollins@openldap.org  --  bcollins@linux.com  '
 `---=========------=======-------------=-=-----=-===-======-------=--=---'



Reply to: