On Thu, 1 Dec 2011, Adrian Schröter wrote:
Am Donnerstag, 1. Dezember 2011, 15:11:40 schrieb Richard Guenther:
On Thu, 1 Dec 2011, Adrian Schröter wrote:
Am Donnerstag, 1. Dezember 2011, 15:01:08 schrieb Richard Guenther:
On Thu, 1 Dec 2011, Juergen Weigert wrote:
On Dec 01, 11 13:34:52 +0100, Adrian Schröter wrote:
> > I'm testing a new version of the format_spec_file > > service > > It makes reviewing local changes impossible for packages > which > generate their spec files automatically from input > files.
Well, our policy is to have a unique layout and we even are required to do so legal wise to some degree.
A new legal requirement is: We adopt the SPDX standard for license names. (E.g. where we had "GPL 2 or later" we now say "GPL-2.0+".) Such name changes need to propagate into your spec file input files. But how does that make reviewing local changes impossible?
I review .spec file changes that result from changing the .spec.in files and re-generating them. But doing so and using osc diff on the .spec file produces a huge unreadable diff now (mostly not due to the license change stuff).
How can I run the formatter on a selected file (in my case, the .spec.in file)?
/usr/lib/obs/service/format_spec_file.files/prepare_spec $in > $out
How does that file magically appear or stay up-to-date? I guess
Via maintenance update. We will do release the required set of services and also the new osc for maintenance work soon hopefully.
I have to play games to stay up-to-date with multiple versions in the different repositories? (12.1 and Factory for now I guess)
No, we should have only one standard regarding the sources.
If there will be a difference in future, we will still have one service, but change modes via server side configurations (extra service parameter per project).
Btw, just added an optional parameter to allow to specify the spec file name. You could use that in your source via adding a _service file with this content:
<services> <service name="format_spec_file" mode="localonly"> <param name="specfile">YOUR_FILE.spec.in</param> <service> </services>
So it will update your file automatically the next time you work on it.
Currently (obs-service-format_spec_file-0.2-39.1) it does (on devel:gcc/gcc47/gcc.spec.in): @@ -18,9 +18,6 @@ # norootforbuild # icecream 0 - -# Ada currently fails to build on a few platforms, enable it only -# on those that work # Note that AdaCore only supports %ix86, x86_64 and ia64 %ifarch %ix86 x86_64 ppc s390 ia64 %define build_ada !0%{?building_libjava:1}%{?building_libffi:1} err? Why does it remove random comments? - -Name: gcc@base_ver@ -BuildRequires: bison flex gettext-devel glibc-devel-32bit mpfr-devel perl texin fo zlib-devel mpc-devel +Name: gcc.spec.in +BuildRequires: bison flex gettext-devel glibc-devel-32bit mpc-devel mpfr-devel perl texinfo zlib-devel Sure changing Name like this is broken. # PACKAGE-BEGIN + %package -n libgomp@base_ver@@variant@ License: GPLv3+ <<ex(GCC Runtime Library Exception 3.1) ?? Please do not add or remove vertical space (seems to be done inconsistently anyway: @@ -477,13 +474,13 @@ # PACKAGE-BEGIN %package -n libada@base_ver@@variant@ License: GPLv3+ <<ex(GCC Runtime Library Exception 3.1) @@ -385,15 +383,14 @@ /sbin/ldconfig # PACKAGE-END - %package info See above. @@ -1798,26 +1804,39 @@ %endif %if %{separate_biarch} + %files -n gcc@base_ver@%{separate_biarch_suffix} randomly changing all vertical space to a single line and then adding such single-line vertical space at random places does reduce readability and overall structure of my spec file. Please refrain from doing that. @@ -1834,24 +1853,34 @@ %endif %mainlib libstdc++.so.* + %if %{separate_biarch} err - and here we're changing vertical space to two lines ... (consider removing all vertical space munging - it seems to be a mess and broken - now I'm curious on how you'd deal with "reverting" bogus vertical space changes ;)). Minus the vertical space issue, the Name: mangling and the toplevel comment removal then changes look good. But I obviously cannot apply a patch like the one produced. Sorry. Richard.