Fixing wrong Bootstrapping part in Guidelines
by Jun Aruga
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
5 years, 1 month
Which Fedora/EPEL is targeted by packaging guidelines?
by Vít Ondruch
Hi all,
Reading logs from yesterdays FPC meeting [1], I think we should discuss
what is actually purpose of packaging guidelines and which version of
Fedora/EPEL/RHEL they actually targets.
Apparently, there are two camps of packagers in Fedora/EPEL. Those who want:
1) single version of .spec file to cover the whole Red Hat ecosystem.
2) clean .spec file following the latest and greatest packaging practices.
I personally belong to the group (2) and that is for several reasons:
a) I use Rawhide on daily basis and I develop only for Rawhide. If I do
changes in older Fedoras, then it is typically just bug fixes and
honestly, that does not happen often (I am POC of ~200 packages and I
submitted just 40 updates during last year [2]). And in fact, this is
official philosophy of updates [3], not just mine.
b) I spent time developing features which should simplify packaging (for
example in F27+, the RPM %setup macro can expand the .gem packages) and
I want to use these technologies to simplify my life and life of others.
c) As a proven packager and person who typically does rebuild of Ruby
packages, I really hate the branched .spec files where nobody knows what
was the purpose of the branches, most of the branches are for obsolete
and unsupported releases etc. It is quite hard to apply any improvements
into such packages. Moreover it is not realistic to test them. If they
were maintained, it would be different story, but the reality is different.
Don't get me wrong, I understand that there are packagers who has just
handful of packages and it is better for them to maintain just single
.spec file with all the branches and I don't mind them as long as the
packages are really actively maintained. But this approach just don't
scale and should be exception and not recommended practice.
To sum this up, my take on packaging guidelines is that *the guidelines
should document the most recent practices available in Rawhide and this
should be documented*. Covering all the exceptions necessary for older
Fedoras (not even mentioning RHEL/EPEL) makes the guidelines unreadable
and what is worse, they slow down entire development of Fedora.
Vít
[1]
https://lists.fedoraproject.org/archives/list/packaging@lists.fedoraproje...
[2] https://bodhi.fedoraproject.org/updates/?user=vondruch
[3] https://pagure.io/packaging-committee/issue/710
5 years, 10 months
Summary/Minutes from today's FPC Meeting (2017-11-29 18:00 - 18:50 UTC)
by James Antill
======================
#fedora-meeting-2: fpc
======================
Meeting started by geppetto at 18:00:26 UTC. The full logs are
available
at
https://meetbot.fedoraproject.org/fedora-meeting-2/2017-11-29/fpc.2017-
11-29-18.00.log.html
.
Meeting summary
---------------
* Roll Call (geppetto, 18:00:27)
* Schedule (geppetto, 18:06:41)
* LINK:
https://lists.fedoraproject.org/archives/list/packaging@lists.fedor
aproject.org/message/6IGVASP6DMJVUJ2HNZAFQPVWURIGZ67J/
(geppetto, 18:06:43)
* #720 Easy way of changing/removing shebangs (geppetto, 18:07:04)
* #726 Review for SELinux Independent Policy packaging
Draft (geppetto,
18:08:38)
* Shouldn't be recommending external services. (geppetto, 18:15:48)
* Open Floor (geppetto, 18:22:01)
* LINK: https://pagure.io/packaging-committee/issue/729 (tibbs,
18:23:04)
* LINK: https://github.com/fedora-infra/fresque (tibbs, 18:27:25)
* LINK: https://pagure.io/packaging-committee/issue/710 ? (geppetto,
18:45:23)
Meeting ended at 18:50:36 UTC.
Action Items
------------
Action Items, by person
-----------------------
* **UNASSIGNED**
* (none)
People Present (lines said)
---------------------------
* tibbs (58)
* geppetto (45)
* limburgher (24)
* zodbot (10)
* sgallagh (6)
* tomspur (4)
* orionp (1)
Generated by `MeetBot`_ 0.1.4
.. _`MeetBot`: http://wiki.debian.org/MeetBot
6 years
Re: [Guidelines change] Changes to the packaging guidelines
by Remi Collet
Le 28/10/2017 à 01:47, Jason L Tibbitts III a écrit :
> A new section was added to the packaging guidelines regarding shebang
> lines. It forbids the use of 'env' and codifies the longstanding rpmlint
> rule that non-executable files should not have shebang lines.
I strongly disapproved this new forbidden use of env.
It works perfectly and have lot of benefits, at least for SCL users,
especially for PHP stack where compatibility is very good between version.
Yes, I have a huge usage of multi-versions of the language installed and
used simultaneously.
Switching back to hard coded path to PHP binary will be, IMHO, a huge
regression for PHP developers.
I won't change any of my package.
Remi.
6 years, 1 month
