Packaging - Plasma Browser Integration extension nodejs dependencies

[Onuralp SEZER]

Hello all,

Fedora KDE has a plasma-browser-integration[0] package it doesn't include the
"actual browser" extension[1] in our repository. 
I want to add  the plasma-browser-integration/firefox extension[2][3] "xpi" into
the "plasma-browser-integration" package. 
However, I need to download the "web-ext"[4] package and a bunch of additional
requirements in it. Is it ok to download 
all the requirements directly, show them as a separate source, get the xpi file directly,
and delete the others, without 
doing package entire nodejs dependencies? What do you think? Am I missing some obvious
solution, or is this a sane 
way forward? Any feedback and help would appreciate it. 



Current plasma browser integration spec:
https://src.fedoraproject.org/rpms/plasma-browser-integration


[0] : https://community.kde.org/Plasma/Browser_Integration
[1] : https://addons.mozilla.org/en-US/firefox/addon/plasma-integration/
[2] : https://invent.kde.org/plasma/plasma-browser-integration
[3] : https://invent.kde.org/plasma/plasma-browser-integration/-/tree/master/ex...
[4] : https://www.npmjs.com/package/web-ext


Thank you.
Onuralp

[Troy Dawson]

I see two ways to do this.
First: Since web-ext is a nodejs binary, you could create the web-ext rpm.
If you do this, make sure to use the nodejs bundled library script,[1] to
bundle the build-time, and run-time dependencies.  You would then just add
web-ext as a build dependency when you are building your package.

Second: You could bundle web-ext as a build-only bundle.  You might need to
edit the bundler script, but it often works without modifications.  If you
go this route, you will need to run the bundler script each time you do an
update of your main package.  This will catch any security updates that
have been released since last time.  A sample spec file will help some.[2]

It's looking like you are leaning towards the second option.

Troy

[1] -
https://src.fedoraproject.org/rpms/nodejs-packaging/raw/rawhide/f/nodejs-...
[2] -
https://docs.fedoraproject.org/en-US/packaging-guidelines/Node.js/#_examp...

On Wed, Jun 2, 2021 at 4:19 AM Onuralp SEZER <
thunderbirdtr(a)fedoraproject.org&gt; wrote:

>  Hello all,
>
>  Fedora KDE has a plasma-browser-integration[0] package it doesn't include
>  the "actual browser" extension[1] in our repository.
>  I want to add  the plasma-browser-integration/firefox extension[2][3]
>  "xpi" into the "plasma-browser-integration" package.
>  However, I need to download the "web-ext"[4] package and a bunch of
>  additional requirements in it. Is it ok to download
>  all the requirements directly, show them as a separate source, get the xpi
>  file directly, and delete the others, without
>  doing package entire nodejs dependencies? What do you think? Am I missing
>  some obvious solution, or is this a sane
>  way forward? Any feedback and help would appreciate it.
>
>
>
>  Current plasma browser integration spec:
>  https://src.fedoraproject.org/rpms/plasma-browser-integration
>
>
>  [0] : https://community.kde.org/Plasma/Browser_Integration
>  [1] : https://addons.mozilla.org/en-US/firefox/addon/plasma-integration/
>  [2] : https://invent.kde.org/plasma/plasma-browser-integration
>  [3] :
>  https://invent.kde.org/plasma/plasma-browser-integration/-/tree/master/ex...
>  [4] : https://www.npmjs.com/package/web-ext
>
>
>  Thank you.
>  Onuralp
>  _______________________________________________
>  nodejs mailing list -- nodejs(a)lists.fedoraproject.org
>  To unsubscribe send an email to nodejs-leave(a)lists.fedoraproject.org
>  Fedora Code of Conduct:
>  https://docs.fedoraproject.org/en-US/project/code-of-conduct/
>  List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>  List Archives:
>  https://lists.fedoraproject.org/archives/list/[e-mail]
>  Do not reply to spam on the list, report it:
>  https://pagure.io/fedora-infrastructure
>

[Neal Gompa]

On Wed, Jun 2, 2021 at 12:39 PM Troy Dawson <tdawson(a)redhat.com&gt; wrote:
>  I see two ways to do this.
>  First: Since web-ext is a nodejs binary, you could create the web-ext rpm.  If you do
> this, make sure to use the nodejs bundled library script,[1] to bundle the build-time, and
> run-time dependencies.  You would then just add web-ext as a build dependency when you are
> building your package.
>
>  Second: You could bundle web-ext as a build-only bundle.  You might need to edit the
> bundler script, but it often works without modifications.  If you go this route, you will
> need to run the bundler script each time you do an update of your main package.  This will
> catch any security updates that have been released since last time.  A sample spec file
> will help some.[2]
>
>  It's looking like you are leaning towards the second option.
>  
If it's a nodejs binary, we should probably package it as an RPM and
do the bundling thing for all the stuff it needs. That way, other
extensions can use it too.



-- 
真実はいつも一つ！/ Always, there's only one truth!

[Stephen Gallagher]

On Wed, Jun 2, 2021 at 12:52 PM Neal Gompa <ngompa13(a)gmail.com&gt; wrote:
>  On Wed, Jun 2, 2021 at 12:39 PM Troy Dawson <tdawson(a)redhat.com&gt; wrote:
>  >
>  > I see two ways to do this.
>  > First: Since web-ext is a nodejs binary, you could create the web-ext rpm.  If you
> do this, make sure to use the nodejs bundled library script,[1] to bundle the build-time,
> and run-time dependencies.  You would then just add web-ext as a build dependency when you
> are building your package.
>  >
>  > Second: You could bundle web-ext as a build-only bundle.  You might need to edit the
> bundler script, but it often works without modifications.  If you go this route, you will
> need to run the bundler script each time you do an update of your main package.  This will
> catch any security updates that have been released since last time.  A sample spec file
> will help some.[2]
>  >
>  > It's looking like you are leaning towards the second option.
>  >
>
>  If it's a nodejs binary, we should probably package it as an RPM and
>  do the bundling thing for all the stuff it needs. That way, other
>  extensions can use it too. 
I agree, the first option is preferred.

[Onuralp SEZER]

Hello;

I made the package review request : https://bugzilla.redhat.com/show_bug.cgi?id=1967805, 
But I need help about licenses(I don't know how to handle bundle license) secondly I
may be missing something on spec file, so If anyone has  a time review would be amazing.

Thank you.