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-09-27 16:00 - 16:50 UTC)
by James Antill
======================
#fedora-meeting-1: fpc
======================
Meeting started by geppetto at 16:00:07 UTC. The full logs are
available
at
https://meetbot.fedoraproject.org/fedora-meeting-1/2018-09-27/fpc.2018-
09-27-16.00.log.html
.
Meeting summary
---------------
* Roll Call (geppetto, 16:00:08)
* Schedule (geppetto, 16:06:13)
* LINK:
https://lists.fedoraproject.org/archives/list/packaging@lists.fedor
aproject.org/message/CLIG7B6RWI2D6LDIDIIJD345PJ2Y2RUI/
(geppetto, 16:06:15)
* #795 Nice diffs in git-based guidelines (geppetto, 16:06:27)
* ACTION: use Semantic Breaks for our guidelines code (+1:7, 0:0,
-1:0) (geppetto, 16:15:08)
* #667 Recommend use of systemd sandboxing directives (geppetto,
16:15:36)
* ACTION: Recommend use of systemd sandboxing directives (+1:6, 0:0,
-1:0) (geppetto, 16:34:51)
* Open Floor (geppetto, 16:34:56)
Meeting ended at 16:50:35 UTC.
Action Items
------------
* use Semantic Breaks for our guidelines code (+1:7, 0:0, -1:0)
* Recommend use of systemd sandboxing directives (+1:6, 0:0, -1:0)
Action Items, by person
-----------------------
* **UNASSIGNED**
* use Semantic Breaks for our guidelines code (+1:7, 0:0, -1:0)
* Recommend use of systemd sandboxing directives (+1:6, 0:0, -1:0)
People Present (lines said)
---------------------------
* tibbs (43)
* geppetto (43)
* mhroncok (22)
* redi (22)
* zodbot (15)
* decathorpe (8)
* ignatenkobrain (7)
* limburgher (3)
Generated by `MeetBot`_ 0.1.4
.. _`MeetBot`: http://wiki.debian.org/MeetBot
4 years, 8 months
Summary/Minutes from today's FPC Meeting (2018-09-20 16:00 - 16:50 UTC)
by James Antill
======================
#fedora-meeting-1: fpc
======================
Meeting started by geppetto at 16:01:34 UTC. The full logs are
available
at
https://meetbot.fedoraproject.org/fedora-meeting-1/2018-09-20/fpc.2018-
09-20-16.01.log.html
.
Meeting summary
---------------
* Roll Call (geppetto, 16:01:42)
* Open Floor (geppetto, 16:10:36)
* #727 convert guidelines to git and restructured text (geppetto,
16:19:30)
* LINK:
https://pagure.io/fork/ignatenkobrain/packaging-committee/commits/g
uidelines
(ignatenkobrain__, 16:30:44)
* ACTION: Nobody should touch the wiki, at this point. (geppetto,
16:46:25)
Meeting ended at 16:51:12 UTC.
Action Items
------------
* Nobody should touch the wiki, at this point.
Action Items, by person
-----------------------
* **UNASSIGNED**
* Nobody should touch the wiki, at this point.
People Present (lines said)
---------------------------
* ignatenkobrain__ (24)
* tibbs (20)
* geppetto (20)
* zodbot (16)
* ignatenkobrain (9)
* redi (9)
* bexelbie (8)
* sdgathman (4)
* x3mboy (4)
* limburgher (3)
* redit (0)
Generated by `MeetBot`_ 0.1.4
.. _`MeetBot`: http://wiki.debian.org/MeetBot
4 years, 8 months
Re: DNF: "There are following alternatives to this package"
by Tomas Orsava
On 09/13/2018 06:43 PM, Mathieu Bridon wrote:
> On Thu, 2018-09-13 at 18:17 +0200, Tomas Orsava wrote:
>> We'd like to propose a new functionality for dnf: When a user tries
>> to install a package XYZ and dnf doesn't find it, dnf would recommend
>> them alternative packages. These offered packages would advertise
>> that they are an alternative for XYZ using a specially formatted
>> Provides tag.
>>
>> For example, packages `python2-requests` and `python3-requests`
>> would both have the following tag:
>>
>> Provides: alternative-for(python-requests) = %{version}-
>> %{release}
>>
>> (Possibly via the already existing and widespread %python_provide
>> macro in the Python case.)
>>
>> And when the user would try to install `python-requests`, dnf would
>> look for packages with the relevant Provides tag and display them:
>>
>> # dnf install python-requests
>> * There are following alternatives to this package:
>> python2-requests python3-requests
>> No match for argument: python-requests
>> Error: Unable to find a match
>>
>> This would be very similar to an already existing functionality that
>> searches for lowercase package names:
>>
>> # dnf install python3-REQUESTS
>> * Maybe you meant: python3-requests
>> No match for argument: python3-REQUESTS
>> Error: Unable to find a match
>>
>> (That functionality is broken in some versions—RHBZ#1628514—so you
>> might not see this result at the moment.)
>>
>> What are your thoughts?
> It's neat, but it doesn't help catch typos, which seems like the most
> probably case where I'd want such a feature.
>
> How about instead of a scheme based on provides, just quickly check if
> a package has a "similar" name?
>
> Basically extend the existing check for lowercase you mention.
Catching typos would be useful, and I'd certainly support that addition,
but this doesn't really scratch the itch I'm trying to solve.
We want to tell the user "these are exactly the alternatives available
to you". Not guess, not rely on some typo resolution. We know what the
alternatives are, here they are.
I've talked with people working on dnf and this looks like an easy
mechanism to add, and it will be more reliable for the use cases it covers.
Tomas
>
> $ git stats
> git: 'stats' is not a git command. See 'git --help'.
>
> The most similar command is
> status
>
>
4 years, 8 months
DNF: "There are following alternatives to this package"
by Tomas Orsava
Hi!
We'd like to propose a new functionality for dnf: When a user tries to
install a package XYZ and dnf doesn't find it, dnf would recommend them
alternative packages. These offered packages would advertise that they
are an alternative for XYZ using a specially formatted Provides tag.
For example, packages `python2-requests` and `python3-requests` would
both have the following tag:
Provides: alternative-for(python-requests) = %{version}-%{release}
(Possibly via the already existing and widespread %python_provide macro
in the Python case.)
And when the user would try to install `python-requests`, dnf would look
for packages with the relevant Provides tag and display them:
# dnf install python-requests
* There are following alternatives to this package:
python2-requests python3-requests
No match for argument: python-requests
Error: Unable to find a match
This would be very similar to an already existing functionality that
searches for lowercase package names:
# dnf install python3-REQUESTS
* Maybe you meant: python3-requests
No match for argument: python3-REQUESTS
Error: Unable to find a match
(That functionality is broken in some versions—RHBZ#1628514—so you might
not see this result at the moment.)
What are your thoughts?
One possible addition would be to include a parameter for weight in the
Provides tag, so that python3-requests could be listed as the preferred
option before python2-requests.
All the best,
Tomas Orsava
4 years, 8 months