Bug#297769: patch
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
Reply to: