After we voted on and accepted the last small logic change for the bootstrapping guidelines, vondruch had further comments. To keep that ticket from becoming a confusing morass, I've opened this one.
The guideline in question is: https://fedoraproject.org/wiki/Packaging:Guidelines#Bootstrapping
The basic issue, if I understand it correctly, is that there's confusion about why we define the bootstrap macro in terms of _with_bootstrap when: # You can't specify --with/--without options to koji. # The guidelines say you have to edit the definition anyway, which means that you would change the meaning of the --with-bootstrap flag if you could actually use it.
So, umm, proposal:
Change: {{{ %{!?_with_bootstrap: %global bootstrap 1} }}} to: {{{ %global bootstrap 1 }}}
vondruch, does that adequately summarize your concerns?
The {{{%{!?_with_bootstrap: %global bootstrap 1}}} was proposed to allow koji (and probably copr) to use this macro in the future. I can already use it with mock (if it is in {{{%{?_with_bootstrap: %global bootstrap 1}}} form).
But otherwise, you still need the {{{%global bootstrap 1}}} for the bootstrap build ATM.
We discussed this at today's meeting (http://meetbot.fedoraproject.org/fedora-meeting-1/2015-03-12/fpc.2015-03-12-17.00.txt):
I think I'm going to declare this done. No matter what you do, you'll have to edit something in the spec to force the mode you want for koji. FPC would welcome a proposal upon which we could vote, so feel free to reopen this ticket if you'd like to provide one.
Metadata Update from @vondruch: - Issue assigned to tibbs
@james @tibbs
https://fedoraproject.org/wiki/Packaging:Guidelines#Bootstrapping
Below part in the page, looks wrong or confusing me. the _with_bootstrap's meaning is opposite. I want someone to change part.
%{!?_with_bootstrap: %global bootstrap 1}
For example I want to control the _with_bootstrap variable by mock --define 'define _with_bootstrap 1' or mock (without --define).
mock --define 'define _with_bootstrap 1'
mock
--define
Also using the negative operator !? is more complicated to understand the sentence.
!?
@vondruch 's suggestion is better.
%{?_with_bootstrap: %global bootstrap 1}
Typo.
`mock --define 'define _with_bootstrap 1'
mock --define '%global _with_bootstrap 1'
Sorry again. Above sample was wrong.
Let me show you correct example. See man mock --define for detail.
man mock
Sample.
$ fedpkg co rubygem-actionpack $ cd rubygem-actionpack
Insert dummy BuildRequires inside of the bootstrap if statement.
BuildRequires
$ sed -i '28 a\BuildRequires: rubygem(dummy)' rubygem-actionpack.spec
The result is like this.
%if ! 0%{?bootstrap} +BuildRequires: rubygem(dummy) BuildRequires: rubygem(activemodel) = %{version}
$ fedpkg srpm
--define '%global _with_bootstrap 1' is failed because of dummy BuildRequires.
--define '%global _with_bootstrap 1'
$ mock -r fedora-rawhide-x86_64 --define '%global _with_bootstrap 1' *.src.rpm ... No matching package to install: 'rubygem(dummy)' ... Not all dependencies satisfied Error: Some packages could not be found.
--define '_with_bootstrap 1' is succeeded. dummy BuildRequires is skipped.
--define '_with_bootstrap 1'
$ mock -r fedora-rawhide-x86_64 --define '_with_bootstrap 1' *.src.rpm ... INFO: Results and/or logs in: /var/lib/mock/fedora-rawhide-x86_64/result Finish: run
jaruga Can you open a new ticket to change the bootstrapping guidelines? Also maybe speak to packagers using bootstrapping right now if they are happy to change to the opposite way of doing things?
Metadata Update from @james: - Issue close_status updated to: None (was: Fixed)
@james I can open the ticket. But why is the process to speak to packagers (Maybe on devel ML?) is necessary? The decision maker is not you? You are not confident that current document is wrong?
@james Could you tell me your process to make a decision?
Below process? I suppose that is packaging commitee's responsibility.
@james The purpose of this ticket was always to get %{?_with_bootstrap: %global bootstrap 1} 1 but somehow it never happened, although this was closed. Of course I noticed, but I got tired by this.
Obviously since nobody else complained, it just means nobody is really using the gudelines, since they don't really make a sense.
These are the proposed changes:
https://fedoraproject.org/w/index.php?title=User:Vondruch/Bootsrap_guidelines&diff=492334&oldid=492333
Going to create new ticket ...
Opened #684
Thanks to create new page! @vondruch
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)
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>
%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 this ticket should be IMO refused.
Log in to comment on this ticket.