Dne 5.5.2017 v 18:22 Tomasz Kłoczko napsal(a):
> On 5 May 2017 at 15:50, Vít Ondruch <vondruch@xxxxxxxxxx> 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_over_.25define
> "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
_______________________________________________
packaging mailing list -- packaging@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to packaging-leave@xxxxxxxxxxxxxxxxxxxxxxx
