On Apr 27, 2010, at 4:44 AM, Anders F Björklund wrote: > Eric MSP Veith wrote: > >>>> It is not sufficient to check for the api, and eventually the header, >>>> used in the @rpm5.org code ? Look for realisim is the autoconf karma. I >>>> think there is no doubt that they are not wrong. Please, give me a few >>>> days to try to produce something useful for @rpm5.org in this area. >>> >>> Sure, there's no hurry either, this problem has been looming for a while: >> >> I'm perfectly ok with a better solution, either. ;-) I'm no beecrypt expert, >> and having a simple grep -Rh|sort|uniq|sed pipework was by far the easiest >> for getting all headers that are currently required with 5.3. > > The typical failure mode with beecrypt 4.1.2 is: > > ./rpmbc.h:21:26: error: beecrypt/md4.h: No such file or directory > ./rpmbc.h:26:32: error: beecrypt/ripemd128.h: No such file or directory > ./rpmbc.h:27:32: error: beecrypt/ripemd160.h: No such file or directory > ./rpmbc.h:28:32: error: beecrypt/ripemd256.h: No such file or directory > ./rpmbc.h:29:32: error: beecrypt/ripemd320.h: No such file or directory > ./rpmbc.h:31:29: error: beecrypt/sha224.h: No such file or directory > > Those were all added in 4.2.0, so one should be OK: >
Yes, and all those hashes _USED_ to be in -lrpmio, dutifully handed off upstream, checked that they had arrived intact, and then redundant "cruft" removed from RPM, with discussion and opportunities to do something different _BEFORE_ I made the change. I mean I'm used to being flip-flopped, but _PLEASE_ lets try and move forward @rpm5.org somehow even if the linux vendor dinosaurs aren't. > checking for beecrypt/md4.h... no > configure: error: Your version of BEECRYPT is too old > That's almost perfect, except that a test for <md4.h> is almost certainly going to lead to a schoolboy lecture on MD4's insecurities. AutoFu to test <sha24.h> will keep NIST Chauvinist's happy, and while a test for RIPEMD160 is likelier to please EU agenda', the *BSD Bloat! removal activists are gonna want to use what is in -lc instead of what is in BeeCrypt. And around and around and around it goes, sigh ... > > There is a similar failure mode for popt 1.14: > > poptALL.c:352: error: 'POPT_ARGFLAG_TOGGLE' undeclared here (not in a > function) > poptI.c:225: error: 'POPT_ARGFLAG_TOGGLE' undeclared here (not in a function) > poptQV.c:234: error: 'POPT_READFILE_TRIMNEWLINES' undeclared (first use in > this function) > poptQV.c:234: error: (Each undeclared identifier is reported only once > poptQV.c:234: error: for each function it appears in.) > poptQV.c:344: error: 'POPT_ARGFLAG_TOGGLE' undeclared here (not in a function) > This too was planned, discussed, implemented (with legacy retrofits), re-discussed (about a year ago) and then deliberately and consciously removed from RPM. See cvs, look for #if !defined(POPT_ARGFLAG_TOGGLE) #define POPT_ARGFLAG_TOGGLE 0 #endif The POPT_READFILE_TRIMNEWLINES change (and OpenPKG's '@" == "attention" security marker) were another attempt to refactor useful (imho) functionality implemented in multiple places within RPM into an external popt library, another attempt at RPM "cruft" removal. But we can do the AutoFu too ... but please let's try and move @rpm5.org forward somehow. > So I added a similar 1.15 define check, for configure: > > checking if <popt.h> defines POPT_ARGFLAG_TOGGLE... no > configure: error: Your version of POPT is too old > Thanks. There's another place where POPT_ARG_ARGV needs testing/fixing that hows up if you build --with-nix that I will "fix" when I get back to Nix ... 73 de Jeff______________________________________________________________________ RPM Package Manager http://rpm5.org Developer Communication List rpm-devel@rpm5.org
