Package Details: firefox-opensuse-bin 123.0-2

Git Clone URL: (read-only, click to copy)
Package Base: firefox-opensuse-bin
Description: Standalone web browser from with openSUSE patches
Upstream URL:
Keywords: browser gecko web
Licenses: GPL, MPL, LGPL
Conflicts: firefox
Provides: firefox
Submitter: HTV04
Maintainer: Wyn
Last Packager: Wyn
Votes: 2
Popularity: 1.05
First Submitted: 2023-11-28 22:28 (UTC)
Last Updated: 2024-02-25 05:26 (UTC)

Dependencies (18)

Required by (150)

Sources (2)

Pinned Comments

HTV04 commented on 2023-12-02 21:44 (UTC) (edited on 2024-01-20 06:41 (UTC) by HTV04)

firefox-opensuse-bin is different from the firefox package because it includes various patches by the openSUSE team, including patches to better integrate with KDE (i.e. file dialogs). More info:

This package is not to be confused with firefox-kde-opensuse. Although both firefox-opensuse-bin and firefox-kde-opensuse provide better KDE integration, the latter has an additional patch from Ubuntu that provides global menu support. More info:

Finally, despite using the openSUSE patches, this package contains none of the openSUSE Firefox branding, which is contained separately from the Firefox RPM.

Latest Comments

1 2 Next › Last »

HTV04 commented on 2024-02-01 22:03 (UTC)

@Melechtna As of now, this package and kmozillahelper-bin will now update automatically. I found out that has a JSON API that can you can use by appending ?jsontable to any directory URL, and using that I can retrieve the latest RPMs at build time. Problem solved (hopefully).

Let me know if you have any issues with this new setup.

Melechtna commented on 2024-02-01 17:57 (UTC)

This may be..."icky", but, what if you pulled the package from the Mozilla source, and plop it into say, github as temporary storage, or something similar, and have the package build pull from that?

HTV04 commented on 2024-02-01 17:55 (UTC) (edited on 2024-02-01 17:55 (UTC) by HTV04)

@Melechtna And the only way to do that would be either:

  • Use the OSS repo like you suggested, which would mean unnecessarily slower updates

  • Somehow automatically obtain the package version, which would work for both Mozilla and OSS

Given how this package becomes out of date really fast, I am actually considering one of these options, but I would strongly prefer the latter. I know it's possible to obtain this data by scraping the repo XMLs, and I might try experimenting with this approach. But if that fails, I might bite the bullet and use the OSS repo to stabilize this package.

Melechtna commented on 2024-02-01 17:48 (UTC)

Okay, fair, but, that would explain why this issue is occurring, they don't retain the link if another incremental update is pushed, which means, if you grab -2, and they shortly after push -3, besides yourself, everyone else is out an update. So the link needs to be more reliable.

HTV04 commented on 2024-02-01 17:45 (UTC) (edited on 2024-02-01 17:49 (UTC) by HTV04)

@Melechtna I can't add screenshots, so I'll try to visualize it:

OSS repo: MozillaFirefox-122.0-1.1.x86_64.rpm MozillaFirefox-122.0-2.1.x86_64.rpm

Mozilla repo: MozillaFirefox-121.0.1-1.3.x86_64.rpm MozillaFirefox-122.0-3.3.x86_64.rpm

Both repos store two variants of the Firefox package. OSS stores two package releases of 122.0, and Mozilla stores the latest 121.0.1 and 122.0 package releases. The important part is that the Mozilla repo is actually updated faster, which you can see from the package release (2.1 on OSS, 3.3 on Mozilla). Of course, right now, both repos have 122.0, but when, for example, 123.0 is released, the Mozilla repo will get it first, potentially days before the OSS repo gets it. This also more closely aligns with the Arch Firefox package.

Btw, the ARM64 architecture actually falls back to the OSS repo because the Mozilla repo does not produce packages for it. In this commit, you can see where I had to account for when the OSS repo still had 121.0.1 and 122.0 was released on Mozilla:

Hope this makes sense, but if you have any other questions, please let me know.

Melechtna commented on 2024-02-01 17:31 (UTC)

Not sure I understand the difference or why this would even be necessary. Using the oss link, I get the correct version, and it installs fine. Leaving the package build as you have it, about 80% of the time, the links non-working when I get the update notification/can perform an update, and I have to go grab the link from the OSS source, which, unless I'm completely mental, is the exact same.

HTV04 commented on 2024-02-01 17:28 (UTC) (edited on 2024-02-01 17:28 (UTC) by HTV04)

@Melechtna Sorry if I'm wrong, but your link appears to redirect to the standard openSUSE oss repo, which has the same problem as the mozilla repo where only a couple of variants of the same package are stored before being deleted. The only difference between the two repos is that the former updates slower and recieves less hotfixes, which I guess would be more stable at the cost of slower updates.

I would much rather be able to have the package update itself automatically, but I don't know of any APIs that can retrieve the latest package version and release. Again, I can technically hack together a solution that reads this data from the various repo XMLs, but that would not only be hard to implement, given how PKGBUILDs work (I would likely need to write a separate shell script that does the dirty work), but also very hard to maintain.

Melechtna commented on 2024-02-01 13:13 (UTC)

Posting this once more, because I keep forgetting to enable notifications, because I'm a basket case.

Melechtna commented on 2024-02-01 13:11 (UTC)

Sorry, didn't get a notification for your response, not sure exactly what you did, but every time I'd go to update, the link would be invalid, and I'd need to modify the package build to actually point to the right link, which is the one I provided. When I came here to see what was going wrong, the link that was in the sources, would always load a page that stated "resource unavailable" or something similar, so perhaps it's an issue with the window of time before the next update is pushed and this repo, I'm not entirely sure.

Regardless, if the link being used is temporary, which it seems to be, and I happen to update "too late", then probably not the best idea to be using this link method, as the one I posted is more permanent/long lasting, as this is where I'd have to redirect package build every time to get the update to go through.