Tito schrieb: > On Saturday 15 November 2008 10:51:44 walter harms wrote: >> Rob Landley schrieb: >>> On Friday 14 November 2008 09:42:50 walter harms wrote: >>>> hhhmmm, >>>> >>>> releasing a code that depends on a libc version that is not released yet >>>> it not nice to users. >>> I suspect glibc had this years ago and that's what they were testing >>> against. >>> >>> I also note that uClibc had an -rc1, -rc2, and -rc3 in the month of >>> october, >>> and had stated on the mailing list the intention to have a release out at >>> the >>> end of October. In reality, the busybox 1.13.0 and uClibc 0.9.30 releases >>> were essentially synonymous. >>> >> hi Rob, >> >> that may be but if you require the latest feature of the latest release >> you should give the users a hint. >> >> >> >>>> something like >>>> >>>> if uClibc version < 0.9.30 >>>> you need version 0.9.30 at least >>>> exit >>>> end if >>>> >>>> may help also. >>> For a single applet? (Other applets build fine against much older >>> versions.) >>> >>> Would you like to add tests for dietlibc, newlib+libgloss, and klibc as >>> well? >>> Plus the various BSDs people occasionally send in patches for, MacOS X, and >>> mingw? >>> >>> Plus the various non-x86 targets with varying functionality, such as the >>> fact >>> you can't build taskset on m68k under _any_ libc due to the lack of smp >>> processor affinity syscalls? >>> >>> Wanna keep all of the above in sync, for each applet, for each new release >>> of >>> every project? And warn about gcc versions that miscompile things on >>> various >>> hardware targets? >>> >>> Or we could just avoid going down that rathole entirely, and stay simple. >>> I >>> like simple... >> i do not call it *the solution*. Of cause you can not solve every problem. >> This was not intended. But you can help with obvious problems in basic stuff >> like ulibc. and if you aware that the last version of gcc will cause havoc >> why not add a warning ? >> With m68k i am not sure i would assume that m68k people will be aware that >> it has no smp processor affinity. >> >> NTL is is not our business to decide about releases. Denys is the maintainer >> and if he does , he does it. >> IMHO it is unfair to say nothing when i (i do not speak for other people) >> think he >> made a mistake. >> >> re, >> wh >> > > Hi, > i'm the culprit!! ;-) > As the checks for the missing of getgrouplist in uClibc were in > the code.......I would dare to say uglyfied the code and due to > the fact that i did an integral rewrite of id.c I removed them. > The main reason that made me decide to remove the ifdefs was that: > > 1) libc has getgrouplist > 2) getgrouplist was added to libbbpwdgrp > 3) getgrouplist was already in uClibc svn > and the mantainer was talking about releasing soon. > > So for the sake of code cleaness I removed the ifdef hell. > In reality uClibc was 2 days late or we 2 days to early, > this is surely annoying, but was not intended to happen. > Now the problem is resolved anyway.....and we have > clean, readable and maintenable code. > > @Walter > Nonetheless if you want to add some warning or > maybe some advice in the id help text feel free > to send a patch. >
i am guilty also :) since i started patching id, what was the starting reason you did the rewrite. i think a patch is not needed anymore since the needed ulibc is out now. my (only) point was that we should not release SW that needs a ulibc version (a supported libc!) that is not yet released. I am fully aware why this bad timing happened but this is simply a bad habit, no matter what, you can not do that. i thought is important to communicate that. re, wh _______________________________________________ busybox mailing list [email protected] http://busybox.net/cgi-bin/mailman/listinfo/busybox
