Dear Packagers who are using Boostrapping logic for the cyclical dependency
Need your help to fix wrong Bootstrapping part in Guidelines. This mail is long. Sorry for that in advance.
You may be building the cyclical dependency packages by using a variable such as _with_bootstrap, need_bootstrap, bootstrap, enable_test, and etc.. For example, you may build with below ways for that, if you will use mock command.
``` $ mock -r fedora-rawhide-x86_64 --with=bootstrap *.src.rpm => _with_bootstrap can be used as --with=bootstrap $ mock -r fedora-rawhide-x86_64 --define '_with_bootstrap 1' *.src.rpm $ mock -r fedora-rawhide-x86_64 --define 'need_bootstrap 1' *.src.rpm $ mock -r fedora-rawhide-x86_64 --define 'enable_test 1' *.src.rpm ... ```
Here is a document page to unify the Bootstrap logic. You may know it. https://fedoraproject.org/wiki/Packaging:Guidelines#Bootstrapping
However I found that below part in the page is wrong.
``` %{!?_with_bootstrap: %global bootstrap 1} ```
Because .. If _with_bootstrap is not set from outside, bootstrap is 1 => bootstrap is True/Enabled if _with_bootstrap is set as 1 from outside, bootstrap's value is not set. => the value is empty if it is not declared in advance. It's a kind of 0. bootstrap is False/Disabled.
This situation is opposite meaning of "_with_bootstrap".
Below way not using negative operator `!?` is correct.
``` %{?_with_bootstrap: %global bootstrap 1} ```
The reason why I wrote this here is
I found that had already been reported 2 years ago for packaging committee, however it was closed without fixing.
https://pagure.io/packaging-committee/issue/509
I am not sure that why it is not admitted.
You may feel that it does not matter because you may edit the Bootstrapping logic in the RPM spec file manually.
But in my case, I am one of the people who use the Bootsrapping logic actively. There are 89 RPM packages that constitutes Ruby on Rails 5.0. To build Ruby on Rails 5.0 completely from scratch, I have to build the packages total 103 times considering bootstrap.
I am trying to build those packages automatically by a tool [1] with a configuration file [2] for Ruby on Rails. It is important to fix it due to that.
Fortunately today another guy Vit created new ticket for that. So, if YOU like this proposal, please comment in below page of the ticket or reply here. It is helpful for us to move this huge rock. I really want to fix it.
"I like it." comment please. => https://pagure.io/packaging-committee/issue/684
Thank you for your help.
[1] https://github.com/sclorg/rpm-list-builder [2] https://github.com/sclorg/rhscl-rebuild-recipes/blob/master/ror.yml
Kind regards, Jun Aruga
On 5 May 2017 at 13:45, Jun Aruga jaruga@redhat.com wrote:
$ mock -r fedora-rawhide-x86_64 --with=bootstrap *.src.rpm => _with_bootstrap can be used as --with=bootstrap $ mock -r fedora-rawhide-x86_64 --define '_with_bootstrap 1' *.src.rpm $ mock -r fedora-rawhide-x86_64 --define 'need_bootstrap 1' *.src.rpm $ mock -r fedora-rawhide-x86_64 --define 'enable_test 1' *.src.rpm
Few general comments:
1) rpmbuild by default executes %check scripts. This section should be by default *enabled* except few well known cases like gdb (crashes koji) or other doing interactive tests. Disable %check on demand is possible by simple add --nocheck to rpmbuild parameters. No other macros/%bconds are needed. As firing %check is by default active adding any other conditional %ifing is redundant/not needed. In other words only for such cases when it is necessary to *disable by default fire test suit* additional %ifing logic should be used.
2) mock supports --nocheck switch and as the consequence in above example commands should be only "--nocheck" if it is really needed. If bootstrapping needs to disable %check look below
3)
%{?_with_bootstrap: %global bootstrap 1}
Looking on above I have kind of impression that most of the Fedora packages don't know what is the difference between %define and %global. So %global should be used *only* when it is need to overwrite some macro which comes with system resources and other system macros needs to be reevaluated after such redefinition. In other words as long as there there is no anything about <foo> macro in "rpmbuild --showrc | grep <foo>" output should be used %define .. not the %global because it is about defining some macros used only in exact spec file
In existing Fedora spec files probably in +95% cases instead %global should be used %define
4) rpm supports more than 10 years %bconds which simplifies defining and using conditionally activated parts of procedures implemented in spec files. So above quoted line should be never used and only %bcond declaration should be:
%bcond_with boostrap # disable bootstrap by default
(yes .. "%bcond_with foo" disables and "%bcond_without foo" enables foo) Examples how to use macros defined by %bcond:
%if %{with boostrap} BuidRequires: foo %endif
or:
%{?with_bootstrap:BuildRequires: foo}
%build %configure \ --%{?with_bootstrap:en}%{?!with_bootstrap:dis}able-bootstrap \ --<other switches>
or:
%build %configure \ --with%{!?with_boostrap:out}-bootstrap \ --<other switches> or --with-bootstrap%{!?with_boostrap:=off}
%files %{?with_boostrap:%{_bindir>/foo} %{!?with_boostrap:%{_bindir>/bar}
None of the %post/%postun/%pre/%preun/%posttrans* scripts needs to be surrounded by %ifing as exact %files section looks like:
%if %{with boostrap} $files boostrap <%files list> %endif
The same is about "%package boostrap" and all other boostrap subpackage fields. They don't need for example bootstrap additional %ifing as well.
(Above examples are for GNU auotools and it is easy to guess how this can be adapted for other build frameworks)
Sometimes during during bootstrap may be necessary to disable %check
%check %{?with_boostrap:%{__make} check}
no other logic disabling %check is needed because (again) whatever is possible to fire in %check if it is only possible to use should be *enabled* by default.
Summary: what is proposed in https://pagure.io/packaging-committee/issue/509 should be IMO refused.
kloczek
Just to remind the evolution:
https://pagure.io/packaging-committee/issue/469 https://pagure.io/packaging-committee/issue/501
And here it went somehow completely of the track :/
https://pagure.io/packaging-committee/issue/509
Dne 5.5.2017 v 16:03 Tomasz Kłoczko napsal(a):
On 5 May 2017 at 13:45, Jun Aruga jaruga@redhat.com wrote:
$ mock -r fedora-rawhide-x86_64 --with=bootstrap *.src.rpm => _with_bootstrap can be used as --with=bootstrap $ mock -r fedora-rawhide-x86_64 --define '_with_bootstrap 1' *.src.rpm $ mock -r fedora-rawhide-x86_64 --define 'need_bootstrap 1' *.src.rpm $ mock -r fedora-rawhide-x86_64 --define 'enable_test 1' *.src.rpm
Few general comments:
- rpmbuild by default executes %check scripts. This section should be
by default *enabled* except few well known cases like gdb (crashes koji) or other doing interactive tests. Disable %check on demand is possible by simple add --nocheck to rpmbuild parameters. No other macros/%bconds are needed. As firing %check is by default active adding any other conditional %ifing is redundant/not needed. In other words only for such cases when it is necessary to *disable by default fire test suit* additional %ifing logic should be used.
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 ...
- mock supports --nocheck switch and as the consequence in above
example commands should be only "--nocheck" if it is really needed. If bootstrapping needs to disable %check look below
"--nocheck" is nice, but does not disable the "check" dependency installation. There was probably some ticket requesting this, not sure ...
%{?_with_bootstrap: %global bootstrap 1}
Looking on above I have kind of impression that most of the Fedora packages don't know what is the difference between %define and %global. So %global should be used *only* when it is need to overwrite some macro which comes with system resources and other system macros needs to be reevaluated after such redefinition. In other words as long as there there is no anything about <foo> macro in "rpmbuild --showrc | grep <foo>" output should be used %define .. not the %global because it is about defining some macros used only in exact spec file
In existing Fedora spec files probably in +95% cases instead %global should be used %define
https://fedoraproject.org/wiki/Packaging:Guidelines#.25global_preferred_over...
- rpm supports more than 10 years %bconds which simplifies defining
and using conditionally activated parts of procedures implemented in spec files. So above quoted line should be never used and only %bcond declaration should be:
%bcond_with boostrap # disable bootstrap by default
(yes .. "%bcond_with foo" disables and "%bcond_without foo" enables foo) Examples how to use macros defined by %bcond:
%if %{with boostrap} BuidRequires: foo %endif
or:
%{?with_bootstrap:BuildRequires: foo}
%build %configure \ --%{?with_bootstrap:en}%{?!with_bootstrap:dis}able-bootstrap \ --<other switches>
or:
%build %configure \ --with%{!?with_boostrap:out}-bootstrap \ --<other switches> or --with-bootstrap%{!?with_boostrap:=off}
%files %{?with_boostrap:%{_bindir>/foo} %{!?with_boostrap:%{_bindir>/bar}
None of the %post/%postun/%pre/%preun/%posttrans* scripts needs to be surrounded by %ifing as exact %files section looks like:
%if %{with boostrap} $files boostrap <%files list> %endif
The same is about "%package boostrap" and all other boostrap subpackage fields. They don't need for example bootstrap additional %ifing as well.
(Above examples are for GNU auotools and it is easy to guess how this can be adapted for other build frameworks)
Sometimes during during bootstrap may be necessary to disable %check
%check %{?with_boostrap:%{__make} check}
no other logic disabling %check is needed because (again) whatever is possible to fire in %check if it is only possible to use should be *enabled* by default.
Summary: what is proposed in https://pagure.io/packaging-committee/issue/509 should be IMO refused.
May be we should go with the "%bcond_with bootstrap" ... I might update the draft from [1] or prepare different version for FPC.
Vít
[1] https://lists.fedoraproject.org/archives/list/packaging@lists.fedoraproject....
On 5 May 2017 at 15:50, Vít Ondruch vondruch@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.
"--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 .. :)
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...
"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 :)
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" :) ).
kloczek
On May 5, 2017 6:24 PM, "Tomasz Kłoczko" kloczko.tomasz@gmail.com wrote:
On 5 May 2017 at 15:50, Vít Ondruch vondruch@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.
"--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 .. :)
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
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 :)
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" :) ).
Thanks, your opinion is very important for us. Please, keep just talking without taking any actions.
kloczek -- Tomasz Kłoczko | LinkedIn: http://lnkd.in/FXPWxH _______________________________________________ packaging mailing list -- packaging@lists.fedoraproject.org To unsubscribe send an email to packaging-leave@lists.fedoraproject.org
On 5 May 2017 at 17:26, Igor Gnatenko ignatenko@redhat.com wrote:
Thanks, your opinion is very important for us. Please, keep just talking without taking any actions.
Instead using empty sarcasm if you agree with some opinions or see that some ideas are OK all what is necessary to do is add comment like "I think that it is OK [because A, B, D ..]. Please do X, Y, Z to make this real." If you are thinking that everyone knows what kind of action needs to taken .. yes you are 100% right you are only thinking that it is truth. Even if action which needs to be taken is known usually before taking first step of those actions people are discussing .. because someone opinion may be incorrect. Isn't it? Maybe it is not obvious but I'm not assuming that I'm always right.
kloczek
On Fri, May 5, 2017 at 6:22 PM, Tomasz Kłoczko kloczko.tomasz@gmail.com wrote:
On 5 May 2017 at 15:50, Vít Ondruch vondruch@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.
"--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 .. :)
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#.25globa
l_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 :)
it looks like about 8 years ago a campaign started to replace **all** %define with %global so packagers don't use %define in local scopes by mistake: https://fedoraproject.org/wiki/PackagingDrafts/global_preferred_over_define
Make a googlesearch for "use global instead of define".
Marcin
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" :) ).
kloczek
Tomasz Kłoczko | LinkedIn: http://lnkd.in/FXPWxH _______________________________________________ packaging mailing list -- packaging@lists.fedoraproject.org To unsubscribe send an email to packaging-leave@lists.fedoraproject.org
On 5 May 2017 at 18:05, Marcin Dulak marcin.dulak@gmail.com wrote:
it looks like about 8 years ago a campaign started to replace **all** %define with %global so packagers don't use %define in local scopes by mistake: https://fedoraproject.org/wiki/PackagingDrafts/global_preferred_over_define
Could you please have look on current use of %global and tell in how many (literally) cases use %global is about "used in nested macro expansions"?
Just first from the edge (alphabetically) use of %global:
[tkloczko@domek SPECS.fedora]$ grep config -w 0ad.spec %global config debug %global config release make %{?_smp_mflags} -C build/workspaces/gcc config=%{config} verbose=1
kloczek
Dne 5.5.2017 v 18:22 Tomasz Kłoczko napsal(a):
On 5 May 2017 at 15:50, Vít Ondruch vondruch@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_over...
"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
Dne 5.5.2017 v 16:50 Vít Ondruch napsal(a):
Dne 5.5.2017 v 16:03 Tomasz Kłoczko napsal(a):
- rpm supports more than 10 years %bconds which simplifies defining
and using conditionally activated parts of procedures implemented in spec files. So above quoted line should be never used and only %bcond declaration should be:
%bcond_with boostrap # disable bootstrap by default
(yes .. "%bcond_with foo" disables and "%bcond_without foo" enables foo) Examples how to use macros defined by %bcond:
%if %{with boostrap} BuidRequires: foo %endif
or:
%{?with_bootstrap:BuildRequires: foo}
%build %configure \ --%{?with_bootstrap:en}%{?!with_bootstrap:dis}able-bootstrap \ --<other switches>
or:
%build %configure \ --with%{!?with_boostrap:out}-bootstrap \ --<other switches> or --with-bootstrap%{!?with_boostrap:=off}
%files %{?with_boostrap:%{_bindir>/foo} %{!?with_boostrap:%{_bindir>/bar}
None of the %post/%postun/%pre/%preun/%posttrans* scripts needs to be surrounded by %ifing as exact %files section looks like:
%if %{with boostrap} $files boostrap <%files list> %endif
The same is about "%package boostrap" and all other boostrap subpackage fields. They don't need for example bootstrap additional %ifing as well.
(Above examples are for GNU auotools and it is easy to guess how this can be adapted for other build frameworks)
Sometimes during during bootstrap may be necessary to disable %check
%check %{?with_boostrap:%{__make} check}
no other logic disabling %check is needed because (again) whatever is possible to fire in %check if it is only possible to use should be *enabled* by default.
Summary: what is proposed in https://pagure.io/packaging-committee/issue/509 should be IMO refused.
May be we should go with the "%bcond_with bootstrap" ... I might update the draft from [1] or prepare different version for FPC.
Thinking about this over the weekend, I think we should keep setting the %boostrap macro and use the %if conditions where necessary. The main advantage of the %bootstrap macro is that you can set it externally. Let me give an example.
You want to run initial build of your distribution in build system (Koji). To enable bootstrapping of all packages, it is enough to have some package which contains this file:
~~~ $ cat %{_rpmconfigdir}/macros.d/macros.bootstrap %bootstrap 1 ~~~
Once the buildroot is configured to contain such package, all the subsequent builds will have this macro defined and hence the packages will run their bootstrap build. This way, you can boostrap the distribution, although the build system (Koji) does not support anything like "--with=bootstrap".
If there is way to use --with=boostrap flag (either rpmbuild or mock supports it), you can conventionally use it.
Actually, the guidelines should probably be extended. The packages build using "boostrap" macro should be marked, i.e. there should be "Provides: bootstrap_build()" or something similar to be able to find such packages later.
Vít
Dne 9.5.2017 v 09:58 Vít Ondruch napsal(a):
Dne 5.5.2017 v 16:50 Vít Ondruch napsal(a):
Dne 5.5.2017 v 16:03 Tomasz Kłoczko napsal(a):
- rpm supports more than 10 years %bconds which simplifies defining
and using conditionally activated parts of procedures implemented in spec files. So above quoted line should be never used and only %bcond declaration should be:
%bcond_with boostrap # disable bootstrap by default
(yes .. "%bcond_with foo" disables and "%bcond_without foo" enables foo) Examples how to use macros defined by %bcond:
%if %{with boostrap} BuidRequires: foo %endif
or:
%{?with_bootstrap:BuildRequires: foo}
%build %configure \ --%{?with_bootstrap:en}%{?!with_bootstrap:dis}able-bootstrap \ --<other switches>
or:
%build %configure \ --with%{!?with_boostrap:out}-bootstrap \ --<other switches> or --with-bootstrap%{!?with_boostrap:=off}
%files %{?with_boostrap:%{_bindir>/foo} %{!?with_boostrap:%{_bindir>/bar}
None of the %post/%postun/%pre/%preun/%posttrans* scripts needs to be surrounded by %ifing as exact %files section looks like:
%if %{with boostrap} $files boostrap <%files list> %endif
The same is about "%package boostrap" and all other boostrap subpackage fields. They don't need for example bootstrap additional %ifing as well.
(Above examples are for GNU auotools and it is easy to guess how this can be adapted for other build frameworks)
Sometimes during during bootstrap may be necessary to disable %check
%check %{?with_boostrap:%{__make} check}
no other logic disabling %check is needed because (again) whatever is possible to fire in %check if it is only possible to use should be *enabled* by default.
Summary: what is proposed in https://pagure.io/packaging-committee/issue/509 should be IMO refused.
May be we should go with the "%bcond_with bootstrap" ... I might update the draft from [1] or prepare different version for FPC.
Thinking about this over the weekend, I think we should keep setting the %boostrap macro and use the %if conditions where necessary. The main advantage of the %bootstrap macro is that you can set it externally. Let me give an example.
IOW, having the %bootstrap macro standardized is the most important thing. If we can set it using --with=bootstrap, that is nice addition, but not the most important thing.
Vít
You want to run initial build of your distribution in build system (Koji). To enable bootstrapping of all packages, it is enough to have some package which contains this file:
$ cat %{_rpmconfigdir}/macros.d/macros.bootstrap %bootstrap 1Once the buildroot is configured to contain such package, all the subsequent builds will have this macro defined and hence the packages will run their bootstrap build. This way, you can boostrap the distribution, although the build system (Koji) does not support anything like "--with=bootstrap".
If there is way to use --with=boostrap flag (either rpmbuild or mock supports it), you can conventionally use it.
Actually, the guidelines should probably be extended. The packages build using "boostrap" macro should be marked, i.e. there should be "Provides: bootstrap_build()" or something similar to be able to find such packages later.
Vít _______________________________________________ packaging mailing list -- packaging@lists.fedoraproject.org To unsubscribe send an email to packaging-leave@lists.fedoraproject.org
Hi,
Thanks for the replying, guys.
Summary: what is proposed in https://pagure.io/packaging-committee/issue/509 should be IMO refused.
May be we should go with the "%bcond_with bootstrap" ... I might update the draft from [1] or prepare different version for FPC.
In my opinion, though we may use "%bcond_with bootstrap" or may use _with_bootstrap, at least below text on the current document is wrong in the point of the meaning, and it should be modified.
``` %{!?_with_bootstrap: %global bootstrap 1} ```
At least below proposal is better than current situation.
``` %{?_with_bootstrap: %global bootstrap 1} ```
By the way, there is still no Assignee for below issue page. Is there how to ask packaging committee guys to assign, and proceed it? Do you know when is the document modified? https://pagure.io/packaging-committee/issue/684
Thanks.
Jun
----- Original Message -----
From: "Vít Ondruch" vondruch@redhat.com To: packaging@lists.fedoraproject.org Sent: Tuesday, May 9, 2017 10:01:19 AM Subject: [Fedora-packaging] Re: Fixing wrong Bootstrapping part in Guidelines
Dne 9.5.2017 v 09:58 Vít Ondruch napsal(a):
Dne 5.5.2017 v 16:50 Vít Ondruch napsal(a):
Dne 5.5.2017 v 16:03 Tomasz Kłoczko napsal(a):
- rpm supports more than 10 years %bconds which simplifies defining
and using conditionally activated parts of procedures implemented in spec files. So above quoted line should be never used and only %bcond declaration should be:
%bcond_with boostrap # disable bootstrap by default
(yes .. "%bcond_with foo" disables and "%bcond_without foo" enables foo) Examples how to use macros defined by %bcond:
%if %{with boostrap} BuidRequires: foo %endif
or:
%{?with_bootstrap:BuildRequires: foo}
%build %configure \ --%{?with_bootstrap:en}%{?!with_bootstrap:dis}able-bootstrap \ --<other switches>
or:
%build %configure \ --with%{!?with_boostrap:out}-bootstrap \ --<other switches> or --with-bootstrap%{!?with_boostrap:=off}
%files %{?with_boostrap:%{_bindir>/foo} %{!?with_boostrap:%{_bindir>/bar}
None of the %post/%postun/%pre/%preun/%posttrans* scripts needs to be surrounded by %ifing as exact %files section looks like:
%if %{with boostrap} $files boostrap <%files list> %endif
The same is about "%package boostrap" and all other boostrap subpackage fields. They don't need for example bootstrap additional %ifing as well.
(Above examples are for GNU auotools and it is easy to guess how this can be adapted for other build frameworks)
Sometimes during during bootstrap may be necessary to disable %check
%check %{?with_boostrap:%{__make} check}
no other logic disabling %check is needed because (again) whatever is possible to fire in %check if it is only possible to use should be *enabled* by default.
Summary: what is proposed in https://pagure.io/packaging-committee/issue/509 should be IMO refused.
May be we should go with the "%bcond_with bootstrap" ... I might update the draft from [1] or prepare different version for FPC.
Thinking about this over the weekend, I think we should keep setting the %boostrap macro and use the %if conditions where necessary. The main advantage of the %bootstrap macro is that you can set it externally. Let me give an example.
IOW, having the %bootstrap macro standardized is the most important thing. If we can set it using --with=bootstrap, that is nice addition, but not the most important thing.
Vít
You want to run initial build of your distribution in build system (Koji). To enable bootstrapping of all packages, it is enough to have some package which contains this file:
$ cat %{_rpmconfigdir}/macros.d/macros.bootstrap %bootstrap 1Once the buildroot is configured to contain such package, all the subsequent builds will have this macro defined and hence the packages will run their bootstrap build. This way, you can boostrap the distribution, although the build system (Koji) does not support anything like "--with=bootstrap".
If there is way to use --with=boostrap flag (either rpmbuild or mock supports it), you can conventionally use it.
Actually, the guidelines should probably be extended. The packages build using "boostrap" macro should be marked, i.e. there should be "Provides: bootstrap_build()" or something similar to be able to find such packages later.
Vít _______________________________________________ packaging mailing list -- packaging@lists.fedoraproject.org To unsubscribe send an email to packaging-leave@lists.fedoraproject.org
packaging mailing list -- packaging@lists.fedoraproject.org To unsubscribe send an email to packaging-leave@lists.fedoraproject.org
On 9 May 2017 at 09:29, Jun Aruga jaruga@redhat.com wrote:
%{!?_with_bootstrap: %global bootstrap 1}
At least below proposal is better than current situation.%{?_with_bootstrap: %global bootstrap 1}
Guys really try to learn how to use %bcond. It does not hurt. You can invent infinite combinations of implementing equivalents o %bconds and it it will be still only nothing more than other NIH consequence. To generate on the official builders some bootstrapped packages all what you need is change temporary settings in only package which is bootstrapped. No global macros is needed .. KISS.
kloczek
Dne 11.5.2017 v 23:03 Tomasz Kłoczko napsal(a):
On 9 May 2017 at 09:29, Jun Aruga jaruga@redhat.com wrote:
%{!?_with_bootstrap: %global bootstrap 1}
At least below proposal is better than current situation.%{?_with_bootstrap: %global bootstrap 1}
Guys really try to learn how to use %bcond. It does not hurt. You can invent infinite combinations of implementing equivalents o %bconds and it it will be still only nothing more than other NIH consequence.
Please understand that there is no way how to use %bcond in Koji (to my knowledge), while there are ways to set the %boostrap macro.
To generate on the official builders some bootstrapped packages all what you need is change temporary settings in only package which is bootstrapped. No global macros is needed .. KISS.
The intention of the guidelines is to keep the .spec file of package untouched for bootstrapping.
Vít
On 12 May 2017 at 10:02, Vít Ondruch vondruch@redhat.com wrote:
Guys really try to learn how to use %bcond. It does not hurt. You can invent infinite combinations of implementing equivalents o %bconds and it it will be still only nothing more than other NIH consequence.
Please understand that there is no way how to use %bcond in Koji (to my knowledge), while there are ways to set the %boostrap macro.
Bootstrapping happens only occasionally. What is the problem wit changing state of the %bcond to push build with bootstrapping exact package?
kloczek
Dne 13.5.2017 v 14:10 Tomasz Kłoczko napsal(a):
On 12 May 2017 at 10:02, Vít Ondruch vondruch@redhat.com wrote:
Guys really try to learn how to use %bcond. It does not hurt. You can invent infinite combinations of implementing equivalents o %bconds and it it will be still only nothing more than other NIH consequence.
Please understand that there is no way how to use %bcond in Koji (to my knowledge), while there are ways to set the %boostrap macro.
Bootstrapping happens only occasionally.
For some packages it is occasionally, for other it is each time (rubygem-rspec* for example).
What is the problem wit changing state of the %bcond to push build with bootstrapping exact package?
The point is to not change the package at all for bootstrapping.
Vít
Finally the modification was updated to the official document. Thank you for your cooperation, guys.
https://pagure.io/packaging-committee/issue/684 https://fedoraproject.org/wiki/Packaging:Guidelines#Bootstrapping
So, if YOU like this proposal, please comment in below page of the ticket or reply here. It is helpful for us to move this huge rock. I really want to fix it.
"I like it." comment please. => https://pagure.io/packaging-committee/issue/684
Thank you for your help.
Jun
Hi,
%dist macro started to include bootstrapping logic in it.
https://src.fedoraproject.org/rpms/fedora-release/blob/1eec2677c462781642229...
%%dist %%{?distprefix}.fc%{dist_version}%%{?with_bootstrap:~bootstrap}
That means we have to change our guideline document for bootstrapping again, right? Below is not enough to enable bootstrapping in %dist macro.
https://fedoraproject.org/wiki/Packaging:Guidelines#Bootstrapping
%{?_with_bootstrap: %global bootstrap 1} ... %if ! 0%{?bootstrap} ... %endif
Possible solution is to define 2 lines for that. (I do not like it)
+%{?_with_bootstrap: %global bootstrap 1} +%{?_with_bootstrap: %global with_bootstrap 1}
Or use %bcond_with, %bcond_without? https://github.com/rpm-software-management/rpm/blob/master/macros.in#L139-L1...
@ignatenkobrain do you have a recommendation for that?
Jun
On Fri, Jun 9, 2017 at 11:10 AM, Jun Aruga jaruga@redhat.com wrote:
Finally the modification was updated to the official document. Thank you for your cooperation, guys.
https://pagure.io/packaging-committee/issue/684 https://fedoraproject.org/wiki/Packaging:Guidelines#Bootstrapping
So, if YOU like this proposal, please comment in below page of the ticket or reply here. It is helpful for us to move this huge rock. I really want to fix it.
"I like it." comment please. => https://pagure.io/packaging-committee/issue/684
Thank you for your help.
Jun _______________________________________________ packaging mailing list -- packaging@lists.fedoraproject.org To unsubscribe send an email to packaging-leave@lists.fedoraproject.org
"JA" == Jun Aruga jaruga@redhat.com writes:
JA> That means we have to change our guideline document for JA> bootstrapping again, right?
The fact that a separate method now exists doesn't invalidate what's present in the current guidelines.
What's really "fun" is that the new magic bootstrapping %dist tweak uses the '~' version operator which is also forbidden by the current guidelines. I did point out the issue but it was committed anyway.
- J<
Dne 22. 10. 18 v 16:44 Jason L Tibbitts III napsal(a):
"JA" == Jun Aruga jaruga@redhat.com writes:
JA> That means we have to change our guideline document for JA> bootstrapping again, right?
The fact that a separate method now exists doesn't invalidate what's present in the current guidelines.
What's really "fun" is that the new magic bootstrapping %dist tweak uses the '~' version operator which is also forbidden by the current guidelines. I did point out the issue but it was committed anyway.
It depends how strictly you read the guidelines. The guidelines says just "The tilde (|~|) notation which alters the way RPM does version comparisons MUST NOT be used." and actually the tilde won't be used by packager, it is going to be used just by the macro on background. If you feel users would be confused by meaning of the tilde, then you might want to extend the guidelines (or infrastructure?) to prohibit shipping bootstrap build of packages, which would be good idea anyway (but hard to do, easier to do when the macro is used).
I still think you should lift the ban (this would make things easier) or at least give an exception (this would make things more confusing).
Vít
"VO" == Vít Ondruch vondruch@redhat.com writes:
VO> It depends how strictly you read the guidelines.
Only if you're trying to play lawyer. The meaning is clear as is, and this new thing does conflict with it.
VO> I still think you should lift the ban (this would make things VO> easier) or at least give an exception (this would make things more VO> confusing).
There is insufficient support for lifting the ban. At this point I'm not going to invest any additional time into making that change.
An exception would certainly be needed if FPC wishes to endorse the current method and doesn't wish to have the contradiction in the guidelines.
(One interesting question is what happens when you have multiple tildes in a single Version: tag. If you can't then that leads to some question about whether it's smart to simply add it blindly as the new method does.)
- J<
On Mon, Oct 22, 2018 at 7:23 PM Jason L Tibbitts III tibbs@math.uh.edu wrote:
"VO" == Vít Ondruch vondruch@redhat.com writes:
VO> It depends how strictly you read the guidelines.
Only if you're trying to play lawyer. The meaning is clear as is, and this new thing does conflict with it.
VO> I still think you should lift the ban (this would make things VO> easier) or at least give an exception (this would make things more VO> confusing).
There is insufficient support for lifting the ban. At this point I'm not going to invest any additional time into making that change.
An exception would certainly be needed if FPC wishes to endorse the current method and doesn't wish to have the contradiction in the guidelines.
(One interesting question is what happens when you have multiple tildes in a single Version: tag. If you can't then that leads to some question about whether it's smart to simply add it blindly as the new method does.)
rpmdev-vercmp 1~a~b~c 1~a~b
18:50:57 1~a~b~c < 1~a~b
- J<
packaging mailing list -- packaging@lists.fedoraproject.org To unsubscribe send an email to packaging-leave@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/packaging@lists.fedoraproject....
On 10/22/18 7:44 AM, Jason L Tibbitts III wrote:
"JA" == Jun Aruga jaruga@redhat.com writes:
JA> That means we have to change our guideline document for JA> bootstrapping again, right?
The fact that a separate method now exists doesn't invalidate what's present in the current guidelines.
What's really "fun" is that the new magic bootstrapping %dist tweak uses the '~' version operator which is also forbidden by the current guidelines. I did point out the issue but it was committed anyway.
Huh. I think I merged this, and I don't see any comment from anyone about the ~, and I guess I missed it too.
If we can revert it and get it working some other way, please submit a PR?
kevin
Dne 22. 10. 18 v 18:28 Kevin Fenzi napsal(a):
On 10/22/18 7:44 AM, Jason L Tibbitts III wrote:
> "JA" == Jun Aruga jaruga@redhat.com writes:
JA> That means we have to change our guideline document for JA> bootstrapping again, right?
The fact that a separate method now exists doesn't invalidate what's present in the current guidelines.
What's really "fun" is that the new magic bootstrapping %dist tweak uses the '~' version operator which is also forbidden by the current guidelines. I did point out the issue but it was committed anyway.
Huh. I think I merged this, and I don't see any comment from anyone about the ~, and I guess I missed it too.
This is the tilde discussion:
https://pagure.io/packaging-committee/issue/398
V.
"KF" == Kevin Fenzi kevin@scrye.com writes:
KF> Huh. I think I merged this, and I don't see any comment from anyone KF> about the ~, and I guess I missed it too.
The problem is that I made my comments on the "upstream" pull request, because I was pinged in it: https://pagure.io/fedora-release/pull-request/120
But that one was cancelled and replaced with the "downstream" PR:
https://src.fedoraproject.org/rpms/fedora-release/pull-request/7
which didn't mention the other one at all. And since I wasn't mentioned, I didn't see the other PR until after it had been merged.
- J<
On Fri, May 12, 2017 at 5:02 AM Vít Ondruch vondruch@redhat.com wrote:
Dne 11.5.2017 v 23:03 Tomasz Kłoczko napsal(a):
On 9 May 2017 at 09:29, Jun Aruga jaruga@redhat.com wrote:
%{!?_with_bootstrap: %global bootstrap 1}
At least below proposal is better than current situation.%{?_with_bootstrap: %global bootstrap 1}
Guys really try to learn how to use %bcond. It does not hurt. You can invent infinite combinations of implementing equivalents o %bconds and it it will be still only nothing more than other NIH consequence.
Please understand that there is no way how to use %bcond in Koji (to my knowledge), while there are ways to set the %boostrap macro.
There are no ways to set arbitrary macros in Koji at this time. There is some work to set per-tag macros: https://pagure.io/koji/pull-request/898
But the per-tag macros are not per-build, as you seem to want.
That said, if you want to set a macro to trigger a bcond, you can just do the following:
macros.bootstrap: %_with_bootstrap 1
The above triggers the "%bcond_with bootstrap" evaluation to true, which enables the bootstrap build. I do this all the time for internal builds with other bconds with my OBS instance for the third-party packages I maintain.
This logic is present in /usr/lib/rpm/macros if you'd like to verify it yourself.
-- 真実はいつも一つ！/ Always, there's only one truth!
Dne 22. 10. 18 v 19:12 Neal Gompa napsal(a):
On Fri, May 12, 2017 at 5:02 AM Vít Ondruch vondruch@redhat.com wrote:
Dne 11.5.2017 v 23:03 Tomasz Kłoczko napsal(a):
On 9 May 2017 at 09:29, Jun Aruga jaruga@redhat.com wrote:
%{!?_with_bootstrap: %global bootstrap 1}
At least below proposal is better than current situation.%{?_with_bootstrap: %global bootstrap 1}
Guys really try to learn how to use %bcond. It does not hurt. You can invent infinite combinations of implementing equivalents o %bconds and it it will be still only nothing more than other NIH consequence.
Please understand that there is no way how to use %bcond in Koji (to my knowledge), while there are ways to set the %boostrap macro.
There are no ways to set arbitrary macros in Koji at this time. There is some work to set per-tag macros: https://pagure.io/koji/pull-request/898
But the per-tag macros are not per-build, as you seem to want.
Nice, didn't know about this possibility.
Nevertheless, with modularity, there are also other ways to set macros in buildroot AFAIK.
Vít
That said, if you want to set a macro to trigger a bcond, you can just do the following:
macros.bootstrap: %_with_bootstrap 1
The above triggers the "%bcond_with bootstrap" evaluation to true, which enables the bootstrap build. I do this all the time for internal builds with other bconds with my OBS instance for the third-party packages I maintain.
This logic is present in /usr/lib/rpm/macros if you'd like to verify it yourself.
-- 真実はいつも一つ！/ Always, there's only one truth! _______________________________________________ packaging mailing list -- packaging@lists.fedoraproject.org To unsubscribe send an email to packaging-leave@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/packaging@lists.fedoraproject....
On 05/05/2017 04:03 PM, Tomasz Kłoczko wrote:
- rpm supports more than 10 years %bconds which simplifies defining
and using conditionally activated parts of procedures implemented in spec files. So above quoted line should be never used and only %bcond declaration should be:
%bcond_with boostrap # disable bootstrap by default
(yes .. "%bcond_with foo" disables and "%bcond_without foo" enables foo)
I don't use %bconds due to this—they absolutely could not be more confusing.
Tomas
packaging@lists.fedoraproject.org
-
Igor Gnatenko -
Igor Gnatenko -
Jason L Tibbitts III -
Jun Aruga -
Kevin Fenzi -
Marcin Dulak -
Neal Gompa -
Tomas Orsava -
Tomasz Kłoczko -
Vít Ondruch