On Sun, 2005-12-11 at 20:40 +0100, Diego 'Flameeyes' Pettenò wrote: > On Sunday 11 December 2005 19:29, Spider (D.m.D. Lj.) wrote: > > How will you deal with the packages that build against glibc iconv but > > not against the separated? > I'll patch them, if they are common packages, ports from FreeBSD, NetBSD, > OpenBSD, DragonFly BSD or DarwinPorts will have patches for them, as they use > libiconv.
Sounds good enough : ) > > > There used to be a lot of issues here, which caused me to hard-mask > > iconv ( still should be hard masked for most/all glibc-based systems ) > > due to the split and mainline packages running out of sync. > That's why the virtual consider glibc first, for systems where glibc is not > present it will go with libiconv. Everyone using glibc *must not* use > libiconv, and it *has* to remain hardmasked for them. Yeah, I certainly -HOPE- that it will retain its blocker vs. glibc, or things may slip downhill on a certain rollercoasterride of party and fun. Not to mention that they claim the same files ;) > But libiconv is unmasked for Gentoo/FreeBSD, Gentoo/NetBSD and Gentoo/OpenBSD > systems, where it's needed to have iconv() function. Aye, I just raised the point that such packages -do- exist and will(I'm still not an optimist) be an issue in the future (tm) for you : ) Anyhow, as long as this doesn't impose the case where some poor sod will get iconv on his glibc system I'm quite happy with the change, no worry from me, and do go ahead with the updated deps for all I care. Just try not to make a mess of things *wink* //Spider -- begin .signature Tortured users / Laughing in pain See Microsoft KB Article Q265230 for more information. end
signature.asc
Description: This is a digitally signed message part
