On Oct 16, 2010, at 12:47 AM, Per Øyvind Karlsen wrote:
> 
>   #------------------------------------------------------------------------
>  +# vendor specific macro configuration.
>  +...@distro_macros@%{load:%{_usrlibrpm}/macros.d/%{_vendor}}
>  +
>  +#------------------------------------------------------------------------
>   # executable(...) configuration.
>   #
>   # Path to scripts to autogenerate executable(foo) script dependencies,
>  @@ .
>  patch -p0 <<'@@ .'

This change isn't right: the vast majority of "vendor" macros
are either build related (where macros.rpmbuild.in is the place)
or dialect peculier (in which case the dialect differences need
to be handled in other ways)

Note that I'm way way way tired of dialectical differences
being _FORCED_ into RPM but luser whining
        RPM doesn't "work"!!!!!!!!!! RPM sux!!!!!!
because of vendor's enhanced confusions.

IOW: I'm increasingly going to enforce a sharp line between
RPM "supported" and vendor "supported" macros. If you want
RPM to "support" the change, then by all means, make an RFE
in order to start the multi-year evolutionary process of changing
the names of macros used by RPM. But I wish to see the change
driven to and end-point where the old "stuff" is removed.

I will delete the above on the -r rpm-5_3 branch momentarily.
Expect all the %{load:...} glue to be retargeted through

# XXX sadly there are path name conflicts that force additional/separate macro
%_usrlibrpmmacros_d     @USRLIBRPM@/macros.d

as well. The reason is that I need to ensure that "make check" is
uncoupled from whatever is installed in /usr/lib/rpm.
        

73 de Jeff

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

Reply via email to