Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=592670 --- Comment #9 from Ralf Corsepius <rc040203@xxxxxxxxxx> 2010-05-18 10:56:44 EDT --- (In reply to comment #8) > (In reply to comment #7) > > (In reply to comment #6) > > > 1.Patch1 is not enough, you should also remove some gcc switches in CFLAGS: -W > > > -Wall -std=c99 -pedantic -Os > > make CFLAGS="$RPM_OPT_FLAGS" linux > > > 3. > > > use install instead of %{__install} > > > > > > rpm --eval %__install > > > /usr/bin/install > > > > > > rpm --eval %__make > > > /usr/bin/make > > > > > > rpm --eval %__rm > > > /usr/bin/rm > > No idea why you are fighting these macros. These macros are correct, there is > > nothing wrong in using them. > > Several months, there's a disscussion in fedora-packaging maillist most > packagers object using those unesscessary macros. Still, there is nothing wrong in using them nor did we ban them. > Actually for seasoned packagers, I think use those macros are acceptable if > they can use them consistently throughout the spec. Actually, technically these macros are superior and cleaner than not using them. The problems with these macros are elsewhere: Once they are being used, rpm can't easily get rid of them. > But, for new packagers, they can hardly use those macros consistently, taken > this spec for a example: The packager choose %{__install}, but still use rm, > make, mkdir. > This breaks the principle of pick one packaging style and use it consistently. > > For me, I always suggest new packagers not to use those macros, few new > packagers can remember those rpm macros which have shorten alternative > commands. Well, for the moment, I abstain to furtherly comment on this. Only so far, you are enforcing a non existing rule. -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. _______________________________________________ package-review mailing list package-review@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/package-review