Joseph S. Myers wrote: > That said, I would question whether this is the right place for this > interface
For avoidance of doubt, I'm not going to argue this point. It seems reasonable to me, but I am not an expert on GLIBC or GNU/Linux system architecture issues. My thought is that putting more of this stuff into (E)GLIBC -- especially given that we have configurability to control what's included -- makes things simpler for people in that they don't have to create/maintain/use zillions of little libraries. I also question whether trying to push things first into FSF GLIBC is important. That undermines our goal of making it easier to get patches into EGLIBC than FSF GLIBC. I guess it's still easier, in that we might accept it if FSF GLIBC rejected it, but it's not an easier process. But, that said, Alexander, Joseph has strong feelings on these issues, and I've not been able to change his mind. Yet. :-) So, you should probably follow his advice, and start by suggesting this to FSF GLIBC. But, first, you'll definitely want to follow his technical advice, which is undoubtedly sound, and save you some pain in the FSF GLIBC submission process. -- Mark Mitchell CodeSourcery [email protected] (650) 331-3385 x713 -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: http://lists.debian.org/[email protected]
