At Fri, 8 Apr 2005 19:13:49 -0400, Daniel Jacobowitz wrote: > On Sat, Apr 09, 2005 at 12:46:24AM +0900, GOTO Masanori wrote: > > At Fri, 8 Apr 2005 15:31:56 +0200, > > Bastian Blank wrote: > > > Also GLIBC_PRIVATE is only used by glibc itself, so the only source of > > > problems may the different glibc packages. But I currently see nothing > > > which may really cause problems here as ld.so is not effected. (See this > > > as a small part of the upgrade to 2.3.4, with the exception that you > > > don't break the compatiblity between ld.so and libc.so.6.) > > > > Yes, exactly, thinking about "upgrade to 2.3.4", it should not make a > > problem. > > > > I'm rathar a bit nervous of supporting this special situation (ex: > > distro compatibility and so on) because -21 should be the last call > > for sarge stuff... > > Could you explain what it is you're worried about? We absolutely > ought to have this patch...
OK, I put the patch. Currently I found the problem about schedutils. Once schedutils `taskset' command uses new sched_getaffinity and sched_setaffinity interface (which has GLIBC_2.3.4), schedutils has to depend on glibc >= 2.3.2.ds1-21. I'm currently searching how to set Depends: libc6 (>= 2.3.2.ds1-21) or libc6.1 (>= 2.3.2.ds1-21) [ia64, alpha] for schedutils. BTW, if we change the library exported symbol version, GLIBC_2.3.4, we should always bump up our shlibs from 2.3.2.ds1-4 to 2.3.2.ds1-21. However, such change affects almost all binaries. Is this acceptable? IMHO, changing shlibs affects a lot of packages, so I would like to take the workaround fix - schedutils and fakeroot just have special Depends: >= 2.3.2.ds1-21, because I guess sched_{get,set}affinity is not used widely. Regards, -- gotom -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]