Nicolas Chauvet venit, vidit, dixit 2026-10-09 18:14:20: > Le ven. 9 oct. 2026 à 16:54, Neal Gompa <[email protected]> a écrit : > > > > On Fri, Oct 9, 2026 at 10:43 AM Nicolas Chauvet <[email protected]> wrote: > > > > > > Le ven. 9 oct. 2026 à 16:04, Neal Gompa <[email protected]> a écrit : > > > > > > > > On Fri, Oct 9, 2026 at 9:59 AM Nicolas Chauvet <[email protected]> > > > > wrote: > > > > > > > > > > Le ven. 9 oct. 2026 à 14:36, Neal Gompa <[email protected]> a écrit : > > > > > > > > > > > > On Fri, Oct 9, 2026 at 8:03 AM Abdallah Shehawey > > > > > > <[email protected]> wrote: > > > > > > > > > > > > > > I am the upstream author of whatsapp-desktop, an independent > > > > > > > GPL-3.0-or-later desktop client for WhatsApp Web with tray > > > > > > > integration, notifications, themes, configurable fonts and privacy > > > > > > > controls. It requires an existing WhatsApp account and Internet > > > > > > > access > > > > > > > and is not affiliated with Meta or WhatsApp. > > > > > > > > > > > > > > I have prepared a source-only application packaging proposal. It > > > > > > > installs JavaScript and data and depends on a separately packaged > > > > > > > Electron >= 40, < 41; the application build neither downloads > > > > > > > Electron > > > > > > > nor runs npm. The application tests and package builds pass in > > > > > > > clean > > > > > > > Ubuntu 24.04 and Fedora 44 environments. Fedora rpmlint reports > > > > > > > zero > > > > > > > errors and warnings. > > > > > > > > > > > > > > Public source review artifacts (Fedora SPEC/SRPM and Debian > > > > > > > .dsc/orig/quilt sources, with checksums): > > > > > > > https://github.com/abdallah-shehawey/whatsapp-desktop/releases/tag/packaging-review-2026-10-09 > > > > > > > > > > > > > > Merged packaging changes and validation: > > > > > > > https://github.com/abdallah-shehawey/whatsapp-desktop/pull/6 > > > > > > > > > > > > > > Debian ITP, acknowledged by the BTS: > > > > > > > https://bugs.debian.org/1150415 > > > > > > > > > > > > > > The key prerequisite is Electron: it is not currently packaged in > > > > > > > the > > > > > > > target official archives, and Debian's runtime request > > > > > > > https://bugs.debian.org/842420 remains open. The ITP is explicitly > > > > > > > blocked on that runtime work. I have not completed Electron source > > > > > > > packaging, and these application artifacts are not an accepted or > > > > > > > currently installable official archive package. > > > > > > > > > > > > > > > > > > > Electron is present in Fedora. It is currently in Rawhide (which > > > > > > will > > > > > > eventually branch to become Fedora 46), but it is present. However, > > > > > > we > > > > > > will only maintain one version of Electron, Right now, > > > > > > nodejs-electron > > > > > > is on v43, and it will likely move to v44 soon. > > > > > > > > > > > > > I would like to pursue inclusion in Fedora's official > > > > > > > repositories. > > > > > > > Could a Fedora packager advise on the Electron prerequisite, > > > > > > > review > > > > > > > eligibility for this independent web-service client, and > > > > > > > sponsorship > > > > > > > for a new contributor? The directly downloadable SPEC and SRPM are > > > > > > > linked above. I understand that a formal Fedora Package Review > > > > > > > must be > > > > > > > filed through a Bugzilla account tied to my Fedora Account System > > > > > > > email; this email is a request for packaging guidance, not a claim > > > > > > > that a formal review has already been filed. > > > > > > > > > > > > > > > > > > > You'll need to update your software to work with newer versions of > > > > > > Electron. I don't know much about your application beyond that, > > > > > > since > > > > > > I haven't looked. Perhaps someone else familiar with Nodejs > > > > > > applications may be willing to look at this once you've updated your > > > > > > code. > > > > > Out of curiosity, which package uses this packaged electron in > > > > > rawhide ? > > > > > > > > > > Having every electron based application to rely on the same pace > > > > > update of the base electron package looks unreliable. That's because > > > > > not every package maintainer can rise up at the same time (not even > > > > > talking about having upstream rebased at the same time, dealing with > > > > > various difficulties or even real life issues). It's not more reliable > > > > > to have a slow pace electron package because it's just moving the same > > > > > problem. > > > > > > > > > > I would prefer to amend the alternate version policy (that allows a > > > > > "per-version" namespace of a given package). > > > > > That way we can have a "per-consumer" based namespace. So having > > > > > electron-whatsapp-desktop and others (signal, elementary, etc). > > > > > > > > > > That's the only way forward to this long standing issue. > > > > > > > > Unless you want to maintain all the different chromium codestreams in > > > > parallel, that's probably not happening. > > > That would be a given. The alternative is to bundle the electron into > > > the "consumer application" which is what is done with the element > > > > > > > It was introduced in order to package podman-desktop, which has a > > > > review request: https://bugzilla.redhat.com/2527713 > > > > > > So it means podman-desktop will control the pace of the > > > nodejs-electron package updates. > > > This is very much "the problem". Another electron enabled package > > > could end-up having a different pace. > > > > > > > Ideally there's a SIG for Electron applications so that it can be > > coordinated and multiple people can work together instead. This is not > > a new problem for us in Fedora and it is generally expected that we > > work with various upstreams to resolve the issue. > > > > > In the whatsapp-desktop case , the electron used is >= 40 < 41. So it > > > will likely never be able to use a system(aka podman paced based) > > > nodejs-electron package. > > > > > > > The packager is the upstream developer. They can fix it. > > I would oppose the same to the podman-desktop maintainer. Electron > upstream is supposed to be at 44.x version, but the packaged version > in rawhide is 43.2 (not even the latest bugfix from 43.7). So it > really means "electron" and consumer versions are tightly coupled.
Exactly. Electron is a prime example for a "runtime" that needs to be available in different versions. Without versioned packages, flatpak is the solution to that. Also, it could help isolate whatever whatsapp is trying to do. As for podman-desktop: I see no explicit version dependency on electron in the spec file. There might be a practical one. OTOH: I don't know why one wouldn't want to use upstream's flatpak. It can't be for fear of containerisation ;-) Michael -- _______________________________________________ devel mailing list -- [email protected] To unsubscribe send an email to [email protected] 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/[email protected] Do not reply to spam, report it: https://forge.fedoraproject.org/infra/tickets/issues/new
