On May 3, 2012, at 1:39 PM, Jeffrey Johnson wrote:

> I haven't any idea what the intent here is: I'm pretty sure its "stuff"
> ported from @rpm.org by Pinto Elia.
> 
> Which is fine … _EXCEPT_ … there's extra dependencies
> being added that are causing most of scripts/* to be erased,
> likely because of a twisted/recursive Makefile dependencies.
> 
> I don't see enough value in fixing implementations whose intent
> isn't clear, so I will revert CRYPTOHASH and brp-python-hardlink
> on Monday (until its fixed).
> 

Let me rip up this patch for illustrative purposes (because
I need to fix it _NOW_: "make clean" is removing scripts/*
files every time, nice KISS feat let/bugture reproducer).

First of all this is just a GNU! GNU! GNU! advocacy fetishism,
totally useless in RPM (and for RPM, because there already is
a single rpm digest command that can replace all this complexity
with a single/simple option selector and is otherwise "drop-=in")

AC_CACHE_CHECK([for a suitable cryptohash command], [ac_cv_path_CRYPTOHASH],
            [AC_PATH_PROGS_FEATURE_CHECK([CRYPTOHASH], [sha512sum sha384sum 
sha224sum sha256sum sha1sum md5sum cksum sum],
              [[cryptohash_out=`echo 'RPM5' | $ac_path_CRYPTOHASH -b 
2>/dev/null`
                test "$?" = 0 \
                && ac_cv_path_CRYPTOHASH="$ac_path_CRYPTOHASH" 
ac_cv_option_CRYPTOHASH="-b" ac_path_CRYPTOHASH_found=:
                test "$?" != 0 -a "$ac_path_CRYPTOHASH_found" != ":" \
                && ac_cv_path_CRYPTOHASH="$ac_path_CRYPTOHASH" 
ac_cv_option_CRYPTOHASH="" ac_path_CRYPTOHASH_found=:]],
              [])], $MYPATH)
AC_SUBST([CRYPTOHASH], [$ac_cv_path_CRYPTOHASH])
AC_SUBST([CRYPTOHASH_OPTION], [$ac_cv_option_CRYPTOHASH])

The only possible reason to wish external One True Crypto is for
FIPS-140-2 NIST "branding", and FIPS-140-2 selection MUST be
also implemented directly in RPM, not with crazy AutoFu.

The implementation that is likely flawed is a brave Newer! Better! Bestest!
effort to partially regenerate and re-expand brp-python-hardlink.in like this:

## brp-python-hardlink make rule
## We don't use configure to do the substitution here; so we must do it
## by hand.  We use a funny notation here to avoid configure
## substitutions in our text.
do_subst = sed \
  -e 's,[@]CRYPTOHASH[@],$(CRYPTOHASH),g' \
  -e 's,[@]CRYPTOHASH_OPTION[@],$(CRYPTOHASH_OPTION),g' \
  -e 's,[@]configure_input[@],Generated from $@.in; do not edit by hand.,g' \
  -e 's,[@]__LN[@],$(__LN),g'

## These files depend on Makefile so they are rebuilt if $(CRYPTOHASH),
## $(__LN) or other do_subst'ituted variables change.
## Use chmod a-w to prevent people from editing the wrong file by accident.
brp-python-hardlink: brp-python-hardlink.in
brp-python-hardlink: Makefile
        $(AM_V_GEN)rm -f $@ $@.tmp
        $(AM_V_at)$(do_subst) $(srcdir)/$@.in >$@.tmp
        $(AM_V_at)chmod +x $@.tmp
        $(AM_V_at)chmod a-w $@.tmp
        $(AM_V_at)mv -f $@.tmp $@

The problem here is that
        brp-python-hardlink: Makefile
dependency gets snarled up with all sorts of AutoFu generated dependencies.
Some cures (like this) are worse than the disease (i.e. needing to
re-run AutoFu to do substitutions into brp-python-hardlink.in.

Now lets see what _REALLY_ needs expanding in brp-python-hardlink.in:

       if [ -f "$pyo" ] ; then
               csha="$(@CRYPTOHASH@ @CRYPTOHASH_OPTION@ "$pyc" | cut -d' ' -f 
1)" && \
               osha="$(@CRYPTOHASH@ @CRYPTOHASH_OPTION@ "$pyo" | cut -d' ' -f 
1)" && \
               if [ "$csha" = "$osha" ] ; then
                       ln -f "$pyc" "$pyo"
               fi
       fi

So brp-python-hardlink needs
        @CRYPTOHASH@            <-- /usr/lib/rpm/bin/rpmdigest is _ALWAYS_ a 
replacement
        @CRYPTOHASH@            <-- this can be passed either as an option, or 
by mapping argv[0] names

So none of the above is really necessary or useful @rpm5.org.

My next check-in will comment out all of the above.

73 de Jeff
> 73 de Jeff
> 
> 

______________________________________________________________________
RPM Package Manager                                    http://rpm5.org
Developer Communication List                        rpm-devel@rpm5.org

Reply via email to