On Mon, Apr 11, 2005 at 12:35:29PM -0400, Daniel Jacobowitz wrote:
> On Tue, Apr 12, 2005 at 01:30:08AM +0900, GOTO Masanori wrote:
> > 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.
> I think that we should just be bumping the shlibdeps; the release team
> has already agreed that we need a glibc update for sarge.
> In any case, the best way to do what you want in schedutils mightb be:
> Depends: ${shlib:Depends}
> Conflicts: libc6 (<= 2.3.2.ds1-21), libc6.1 (<= 2.3.2.ds1-21)
> I think that'll work... but make sure apt can cope.
Apt generally doesn't cope so well with <= conflicts, as they tend to force
the removal of one of the packages on upgrade. Since libc6 isn't going to
get removed, apt generally resolves this as refusing to install or upgrade
the package that has this conflicts until libc is firs upgraded.
Given that other packages may in the future begin to depend on this
interface, I think this should really just be done as a shlibdeps bump.
Cheers,
--
Steve Langasek
postmodern programmer
Attachment:
signature.asc
Description: Digital signature