On Mon, Oct 16, 2000 at 04:23:43PM -0400, Ben Collins wrote:
> Some daemons can be affected by libc upgrades. This usually
> happens if the daemon uses functions related to NSS (username,
> group, hostname and other name lookups). Because these functions
> rely on loading modules (libnss_*.so) that may not match the
> current libc mapped in memory with the program, it may need to be
> restarted when libc is upgraded. The libc package takes care of when
> this needs to occur, but your daemon will need to tell libc that
> it needs to be restarted in this case.
Erm, why should I have to fix libc bugs in my packages? That seems
completely and utterly inappropriate.
Surely there's some other way to work around this, ideally fixing
the root cause not having a zillion other packages work around obscure
incompatible changes in libc?
For example, insisting on libc's dynamic modules to link against *any*
(past, present or future) version of libc or the other modules would fix
this.
Since upstream libc seems to not care seven slightly about compatability,
a possible workaround might be to distribute the old dynamic modules
as well as the new ones, and (somehow) link whichever version will
work. I'm not sure if that's possible, but at least adding cruft to
a single package is better than adding cruft to n other packages for
obscure internal reasons.
But kludging up n other packages because just one is broken isn't the
way we should be doing things.
Cheers,
aj
--
Anthony Towns <aj@humbug.org.au> <http://azure.humbug.org.au/~aj/>
I don't speak for anyone save myself. GPG signed mail preferred.
``We reject: kings, presidents, and voting.
We believe in: rough consensus and working code.''
-- Dave Clark
Attachment:
pgp2LYxddalpn.pgp
Description: PGP signature