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=458866
--- Comment #6 from Björn Persson <bjorn(a)xn--rombobjrn-67a.se> 2009-08-07 09:40:14
EDT ---
(In reply to comment #5)
> Why do you use these macros by the way? What value do they add?
Really now - nothing. But if, when pathes changed - only one system macros
definition must be changed too opposite direct search/replace hundreds of
values.
You mean if the commands were to be moved to some directory not in the default
PATH?
If you were to write "/usr/bin/make", and then make were moved to /bin, then
your script would break, but if you write just "make", then it will still work
as long as make is in one of the directories listed in PATH. Moving these
commands out of the default PATH would annoy lots of people very very much, so
it won't happen. Therefore I think writing "make" is just as future-proof
as
"%{__make}", and it's easier to read. The macros aren't forbidden
though, as
far as I know.
But ppmbuild don't add next requires:
perl(:MODULE_COMPAT_5.10.0)
You should keep that one, according to the guidelines.
perl-Unicode-Map or perl(Unicode::Map)
perl-Spreadsheet-ParseExcel depends on perl(Unicode::Map), so you get that
pulled in by the automatic dependency on perl(Spreadsheet::ParseExcel)
perl-libintl
When I build the package I get an automatic dependency on perl(Locale::Recode),
which perl-libintl provides.
Sorry, I don't want change tabs to spaces.
Well, if this is what you want others to see when they read your spec, it's
your choice:
http://www.rombobjörn.se/diverse/xls2csv.png
It is a requirement that the spec be legible, but this misalignment isn't bad
enough to make it illegible, so I suppose it's allowed.
--
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.