obsolete JavaScript packaging guidelines
by Greg Sheremeta
Hi,
This page
https://fedoraproject.org/wiki/Packaging:JavaScript
is terribly outdated. Even when it was created years ago, IMO the advice
was questionable. Today, it's definitely bad advice.
Modern web applications use webpack for JavaScript. With webpack,
JavaScript is minified and bundled, and sometimes assets are even injected.
I realize bundling libraries is bad for an old-school RPM-based
application. But no one packages JavaScript into RPMs (try to find react
and friends), and the page is leading to confusion on my team.
To prevent confusion, acceptable options would be: either simply deleting
the page, or placing a giant "don't follow this outdated advice" banner at
the top.
Best wishes,
Greg
--
GREG SHEREMETA
SENIOR SOFTWARE ENGINEER - TEAM LEAD - RHV UX
Red Hat NA
<https://www.redhat.com/>
gshereme(a)redhat.com IRC: gshereme
<https://red.ht/sig>
4 years, 6 months
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
4 years, 7 months
Summary/Minutes from today's FPC Meeting (2018-08-30 16:00 - 17:00 UTC)
by James Antill
======================
#fedora-meeting-1: fpc
======================
Meeting started by geppetto at 16:00:11 UTC. The full logs are
available
at
https://meetbot.fedoraproject.org/fedora-meeting-1/2018-08-30/fpc.2018-
08-30-16.00.log.html
.
Meeting summary
---------------
* Roll Call (geppetto, 16:00:35)
* Schedule (geppetto, 16:07:07)
* LINK:
https://lists.fedoraproject.org/archives/list/packaging@lists.fedor
aproject.org/message/SNK64NH3GJAAB3OUMRDSDUSNEU3FE6ZD/
(geppetto, 16:07:08)
* #792 Proposal for "What Can Be Packaged" document (geppetto,
16:07:30)
* Proposal for "What can be in a Package" document (+1:4, 0:0, -1:0)
(geppetto, 16:45:09)
* ACTION: We can have other votes in the ticket. (geppetto,
16:45:23)
* Open Floor (geppetto, 16:45:59)
Meeting ended at 16:58:27 UTC.
Action Items
------------
* We can have other votes in the ticket.
Action Items, by person
-----------------------
* **UNASSIGNED**
* We can have other votes in the ticket.
People Present (lines said)
---------------------------
* geppetto (46)
* tibbs (40)
* mhroncok (32)
* zodbot (12)
* redi (6)
* decathorpe (5)
Generated by `MeetBot`_ 0.1.4
.. _`MeetBot`: http://wiki.debian.org/MeetBot
4 years, 9 months
Summary/Minutes from today's FPC Meeting (2018-08-23 16:00 - 17:00 UTC)
by James Antill
======================
#fedora-meeting-1: fpc
======================
Meeting started by geppetto at 16:00:23 UTC. The full logs are
available
at
https://meetbot.fedoraproject.org/fedora-meeting-1/2018-08-23/fpc.2018-
08-23-16.00.log.html
.
Meeting summary
---------------
* Roll Call (geppetto, 16:00:24)
* Schedule (geppetto, 16:07:49)
* LINK:
https://lists.fedoraproject.org/archives/list/packaging@lists.fedor
aproject.org/message/KYBCQZDT57OJEJAR4BTB6VX3X3AHN6YD/
(geppetto, 16:07:52)
* #785 Crypto policies packaging guideline update (geppetto, 16:08:13)
* Crypto policies packaging guideline update (+1:4, 0:0, -1:0)
(geppetto, 16:23:03)
* ACTION: Everyone/someone else can vote in the ticket (geppetto,
16:23:24)
* #788 Bootstrap Exception for rebar3 (geppetto, 16:23:46)
* Bootstrap Exception for rebar3 (+1:4, 0:0, -1:0) (geppetto,
16:24:54)
* ACTION: Everyone/someone else can vote in the ticket (geppetto,
16:25:00)
* #789 Use bconds everywhere (geppetto, 16:25:11)
* ACTION: mhroncok Will come up with the policy of which cases they
should be used in. (geppetto, 16:36:13)
* ACTION: mhroncok to give a definition of when to use bconds
(mhroncok, 16:36:14)
* #782 Forbid %{pythonX_site(lib|arch)}/* in %files (geppetto,
16:37:32)
* #775 Allow to have %{?suse_version} condition in spec
file (geppetto,
16:39:41)
* Open Floor (geppetto, 16:47:20)
* LINK: https://fedoraproject.org/wiki/Packaging_Committee (tibbs,
16:50:17)
Meeting ended at 16:59:23 UTC.
Action Items
------------
* Everyone/someone else can vote in the ticket
* Everyone/someone else can vote in the ticket
* mhroncok Will come up with the policy of which cases they should be
used in.
* mhroncok to give a definition of when to use bconds
Action Items, by person
-----------------------
* mhroncok
* mhroncok Will come up with the policy of which cases they should be
used in.
* mhroncok to give a definition of when to use bconds
* **UNASSIGNED**
* Everyone/someone else can vote in the ticket
* Everyone/someone else can vote in the ticket
People Present (lines said)
---------------------------
* geppetto (59)
* mhroncok (29)
* tibbs (22)
* zodbot (16)
* digilicious (11)
* ignatenkobrain (4)
* redi (2)
Generated by `MeetBot`_ 0.1.4
.. _`MeetBot`: http://wiki.debian.org/MeetBot
4 years, 9 months
Re: Python Bundled Wheels package
by Miro Hrončok
On 1.8.2018 15:34, Miro Hrončok wrote:
> On 1.8.2018 15:11, Petr Viktorin wrote:
>> On 07/22/18 11:49, Miro Hrončok wrote:
>>> Hi Pythonistas and Fedora packagers.
>>>
>>> Recently I've realized we bundle too much wheels with our pythons +
>>> virtualenv package. That is unfortunate:
>>>
>>> * we don't build those. stricly seeking, it's just a zip with
>>> python files in it, yet this is not permitted in Fedora
>>> * we only sometimes list it as Provides: bundled(...) and when we
>>> do, it is tedious
>>> * we never list bundled deps in those bundled wheels (pip bundles a
>>> lot)
>>> * we never adapt the license tag to include license of bundled
>>> wheels (and bundled deps in those) - it would be even more tedious,
>>> as pip License tag can be very complicated
>>> * we duplicate those across packages
>>>
>>> I went ahead and prepared a concept in:
>>> https://bugzilla.redhat.com/show_bug.cgi?id=1605156
>>>
>>> This is one package that builds all the required wheels. It might be
>>> a bit weird that it's only one package, but I think it can lower the
>>> maintenance burden. Also, we won't update any wheel package, we only
>>> add or remove them, so there is no "life cycle". Later we can decide
>>> that there are simply too many thing sin one package and split it).
>>>
>>> This package makes sure the license tag is right and all the virtual
>>> bundled provides are in place.
>>>
>>> Even as one package, I think it's a big improvement comparing to
>>> current state of things.
>>>
>>> Could you please review the decisions made in the spec? Namely:
>>>
>>> * naming (main package, subpackages)
>>> * virtual provides
>>> * that the spec is generated by a script and how that script works
>>> * the method of usage described in the package review request
>>>
>>> I've also decided not to run tests, as for them to mean something, we
>>> would need to run them against all relevant Python versions. Also, it
>>> would complicate the package a lot.
>>>
>>> The package is approved thanks to Robert-André Mauchin, yet I won't
>>> request the repo until it's settled that we want this.
>>>
>>> Also, once we start using this, maybe we can stop doing rewheel and
>>> just use wheels from here in the python3 package as well?
>>
>> Let me ask: do we actually need all those different versions of
>> wheels? After all, the first thing I do after creating a venv is
>> usually `pip install -U pip`.
>
> The answer is in the middle. No, it doesn't need to be the hardcoded
> one. But for some Python version,s it needs to be relatively old one.
>
> For example virtuelenv now bundles:
>
> argparse = 1.4.0
> pip = 9.0.3
> pip = 10.0.1
> setuptools = 36.8.0
> setuptools = 39.1.0
> wheel = 0.29.0
> wheel = 0.31.1
>
> Just to support Python 2.6, 3.4-3.7.
>
> We may be able to reduce the number of versions. E.g. I don't really
> think we need both 9.0.1 and 9.0.3. Or I don't understand why pypy3
> ships both pip 8.1.2 & 9.0.1; setuptools 21.2.1 & 28.8.0.
>
> We could probably reduce this to:
>
> setuptools
> 36.8.0 for virtualenv (py26)
> 39.1.0 (or newer) for everything else
>
> pip
> 9.0.3 fior virtualenv (py26)
> 10.x or 18.x for everything else
>
> wheel
> 0.29.0 for virtualenv (py26)
> 0.31.1 (or newer) for everything else
>
> argparse-1.4.0 for virtualenv (py26)
We've talked with Petr in person at Flock. Here's a summary:
We'll build wheels packages with our recent pip and setuptools from
python-pip and python-setuptools SRPMs.
We make sure python 2.7 to 3.7 uses them instead of the bundled ones.
That should be fairly easy.
We try to do the same with pypys and Jython (and hope it works).
We'll deal with the Python 2.6 virtuelenv wheels later (probbaly have a
dedicated SRPM for them).
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
4 years, 10 months