On Mon, 2002-12-02 at 05:19, GOTO Masanori wrote: > > This is related to __libc_fork(). The submitter wants glibc to conflict > > with older wine. Do we ever do package-specific conflicts for libc? > > Seems like that would be difficult to maintain. Seems like this really > > is a wine issue; can we close/reassign this? I don't think we need to conflict with packages because of bugs in their package. > IMO, introducing __libc_fork patch resolve all these issue. > In addition, I strongly object to use such a package-specific conflict. > > >From this bug, introducing __libc_fork patch takes us two benefit: > (1) we can safely upgrade from woody to sarge (2) we don't need to > care such conflict. If there is no objection, I commit the patch. I think we need to make a commitment as to when we're removing the patch if we do this. As before, upstream is making no commitment to keeping these hidden interfaces stable and they have already changed some interfaces that are now hidden. So my proposal is that this hack be removed the day after sarge is frozen/released. It also has me wondering if glibc22-m68k-compat.dpatch could be removed then too. We could do a quick check to make sure that anything using lchown with the wrong version number was binNMU'd and drop more baggage. Tks, Jeff Bailey -- When you get to the heart, use a knife and fork. - From instructions on how to eat an artichoke.
Attachment:
signature.asc
Description: This is a digitally signed message part