propozition of specs cleanups

Tomasz Kłoczko kloczek at zie.pg.gda.pl
Sat Feb 4 11:28:16 UTC 2006


Dnia 04-02-2006, sob o godzinie 16:27 +0530, Rahul Sundaram napisał(a):
[..]
> Doing it piecemeal is not going to be worth the effort for you or for 
> the developers without a consensus. So since you have a long list of 
> similar things, it would be better to write one solid proposal for all 
> the changes that you believe needs standardization and send it to the 
> list so that developers can reach consensus on it and follow those 
> guidelines.  Kindly refer to 
> http://fedoraproject.org/wiki/Packaging/Guidelines for existing guidelines.

This document contains very limited informations about specs coding
style. Few poits which are related to subject:

- Build root tag
  but:
  $ grep BuildRoot: *spec | awk '{print $2}' | sort | uniq -c | wc -l
  67
  and .. interesting:
  $ grep BuildRoot: *spec | awk '{print $2}' | sort | grep
'%{_tmppath}/%{name}-%{version}-%{release}-root-%\(%{__id_u} -n\)' | wc
-l
  0

- Parallel make

  In macros set defined in default set wchich comes with rpm you can
  find %{__make} macro. So instead adding some non-standard macro IMO
  better is use standard %{__make}. If someone want perform parallel
  build they simple can "echo '%__make make -j3' >>~/.rpmmacros".

  If someon look for next sed regexp it can be something something like
  "s/make %{?_smp_mflags}/%{__make}/;  s/make %{?_smp_flags}/%{__make}/"

  It is simpler and it is main argument why it will be better use this
  in this form.

- Using %{buildroot} and %{optflags} vs $RPM_BUILD_ROOT and
$RPM_OPT_FLAGS

  This ponit do not clarify which style was choosen by comunity.

And this is all. IMO to short and this mani cause of current style chaos
(which hides big amout of small non-critical bugs like xorg*).

Things like "%{buildroot} vs. $RPM_BUILD_ROOT" are IMO importand because
choosing ony one variant as common allow construct simpler indenting
tools for spec files.

kloczek




More information about the fedora-devel-list mailing list