Dne 5.5.2017 v 18:22 Tomasz Kłoczko napsal(a):
On 5 May 2017 at 15:50, Vít Ondruch <vondruch(a)redhat.com>
wrote:
> Of course it should be enabled by default. This is not elaborated in the
> guidelines, but there still applied "use your best judgement" I hope ...
If you will go over current Fedora specs you can find that it is not
obvious to many package maintainers :)
Many specs contains possibility to *disable* %check probably only
because in FPG is something about doing this without clear explanation
when it should be used.
It might be useful to disable the %check section for various reasons and
--nocheck is not always possible to use, especially if you need to build
the package in some buildsystem (Koji, Copr).
I cannot say if people are using it correctly or not unless you provide
example. Anyway, this is OT for this thread, so you please start another
thread or preferably submit patches via BZ.
> "--nocheck" is nice, but does not disable the "check" dependency
> installation. There was probably some ticket requesting this, not sure ...
Few weeks ago I've proposed here extend spec syntax by add add
CheckRequires field (-> analog to BuildRequires).
So far I did not seen any comment about this idea .. :)
Some people were using BuildRequires(check) syntax up until rpm ~4.8,
where this syntax was disable. Not that it was useful for anything ...
But anyway, this is not the right place for such suggestions and that is
probably why you did not get too much response. However I believe that
PR against RPM upstream would reach the correct audience and could make
a difference.
Discussing it in this thread is OT.
Dependencies listed in CheckRequires should be validated only if
rpmbuild within own pipeline will be executing %check.
So -bp, -bc, -bb, -bi combined with --short-circuit as well, or when
-ba --nocheck is used should not be checking CheckRequires
dependencies.
IMO such extension will solve this kind of cases without using
functional description (%ifing) and only using declarative form of the
description which could be easily processed as well using %dump macro
("rpmbuild -bp --nodeps --define 'prep %dump' <package>.spec").
IMO CheckRequires is only civilized solution as firing %check is
implemented not on the macros layer.
Comments?
[..]
>> In existing Fedora spec files probably in +95% cases instead %global should be
used %define
>
https://fedoraproject.org/wiki/Packaging:Guidelines#.25global_preferred_o...
"Use %global instead of %define, unless you really need only locally
defined submacros within other macro definitions (a very rare case)."
Looks like this sentence is read by most of the packagers up to only "," ..
8-)
Maybe this form is readable for the layers but it does not work for
normal people/engineers.
("Use %global .. unless" almost everyone will be interpreting as "use
%global" as a general approach with <some exceptions> described after
"unless" .. problems is that what is after "unless" is relevant to
majority of the cases -> *it is not the exception* .. because most of
the packagers "need only locally defined submacros" :)
This sentence is kind of perfect example how to write almost every
time incorrectly understood rule :)
Logically this sentence still is 100% correct but reverse form
(putting majority after "unless") is what is not what you could expect
:)
This is OT again. This is probably the right place where you can provide
your feedback:
http://lists.rpm.org/pipermail/rpm-ecosystem/2017-February/000451.html
Seems as same as there is no clear description in FPG about removing
permanently packages by Obsoletes rules and only part which mentions
something about using obsoletes is related to swapping packages names
most of the packages in absence of those rules are using "what is
possible to find" and this is why most of the packagers "use %global
instead of %define: :)
Ergo: FPG is at least in two points waaaay behind how things should be
used or says something which almost everyone incorrectly understands.
It is only a matter of time when someone will find that it is a clash
with some new global macros connected with other macros because
someone overuse of %global in some specs (this is about this "a very
rare case" :) ).
Again OT, but you may submit your proposals for FPC to consider at:
https://pagure.io/packaging-committee/issues/
Vít