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

Re: [installer@ftp-master.debian.org: db1-compat_2.1.3-4_i386.changes ACCEPTED]



On Thu, Aug 15, 2002 at 06:45:05PM +0100, Colin Watson wrote:
> It should be safe to make libc depend on this now, in order to pull in
> libdb.so.2.
> 
> Accepted:
> libdb1-compat_2.1.3-4_i386.deb
>   to pool/main/d/db1-compat/libdb1-compat_2.1.3-4_i386.deb

Upgrading from woody to the current glibc (-13, from -14's changelog I presume
it's the same) breaks:

	apache
	apache-common
	apache-dev
	apache-perl
	apache-ssl
	caudium-php4
	gnucash
	kpackage
	libapache-csacek
	libapache-mod-auth-mysql
	libapache-mod-auth-pam
	libapache-mod-auth-shadow
	libapache-mod-auth-useragent
	libapache-mod-backhand
	libapache-mod-cgi-debug
	libapache-mod-dav
	libapache-mod-filter
	libapache-mod-gzip
	libapache-mod-index-rss
	libapache-mod-interchange
	libapache-mod-ldap
	libapache-mod-lisp
	libapache-mod-mp3
	libapache-mod-python
	libapache-mod-random
	libapache-mod-relocate
	libapache-mod-repository
	libapache-mod-speedycgi
	libapache-mod-text2html
	libapache-mod-trigger
	libapache-mod-webapp
	libapache-mod-witch
	libapache-mod-xslt
	libdb2-util
	libdb3-util
	medusa
	mmorph
	nmh
	ocaml-base
	perspic
	php3
	php4
	php4-cgi
	python1.5
	python2.1
	python2.2
	radiusd-livingston
	smail
	webalizer
	xkbsel
	xkbsel-gnome

I can't see any obvious way to conflict with each of those separately, and 
I guess you don't want to add well over ten lines of Conflicts: to take care
of them. So please add this dependency, already...

According the update_excuses, there are also the following RC bugs:

     * #153263: libc6-prof: unusable on arm
     * #151804: libc6: libbind security hole
     * #152099: an empty directory string in LD_LIBRARY_PATH is
       interpreted as '.'
     * #155606: provide symbols .hidden in gcc 3.1/3.2 when building
       glibc for ppc
     * #156841: glibc_2.2.5-13(alpha/unstable): FTBFS: non-PIC code in a
       dynamic lib

Presumably 156841 was fixed in -14; I've heard rumours that 153263 isn't
an issue anymore either. 152099 seems like it's not being treated by
you guys as "grave", so it should probably be downgraded or closed so
the testing scripts know what's going on. 151804 has a remark indicating
it's been fixed, and should be closed. I don't really follow why 155606
is critical (important, sure, but "breaks unrelated software, the whole
system, causes serious data loss, or introduces a security hole" ?).

Since -13 bumped the shlibs, this has been blocking every package updated
in the last two weeks from entering testing, which isn't healthy.

Cheers,
aj



Reply to: