Chocolatey-coreteampackages: (chromium) follow chrome 'stable' releases, use WebRTC/sync

[AeliusSaionji]

Hello!

The current usage of the chromium package is not what one would expect when installing chromium.

It currently follows "last known good build" and also lacks WebRTC (H.264), widevine (Netflix), and syncing functionality.

This is clearly a package meant for minimal testing- not a fully featured browser one would expect to get.

We need to switch over to a build that includes

• WebRTC
• Sync
• Widevine (unless that can be installed as a separate package)

Furthermore, chromium releases should also be taking advantage of chocolatey's prelease/beta functionality. This package should be kept in-line with the current release of chrome. All these nightly ("last known good build") builds should not be released as new package versions- they should be released as ${version}-beta.

We could optionally provide builds without webrtc, sync, and widevine via packageargs.

I might take a stab at implementing this sometime soon

[AdmiringWorm]

This is clearly a package meant for minimal testing- not a fully featured browser one would expect to get.

While chromium should be a usable browsers, it is less featured than other browsers that are based on chromium (Say: Google Chrome, Opera, Vivaldi, etc...).

It currently follows "last known good build"

Unfortunately, that is the only ones we can get using the API we currently use (from https://chromium.woolyss.com/, I'm considering a change to https://omahaproxy.appspot.com/ though which then would allow us to provide only stable releases)

We need to switch over to a build that includes

• WebRTC
• Sync
• Widevine (unless that can be installed as a separate package)

Do you know of any (provided by google?), the one we currently use is the one provided by google (I think)

Furthermore, chromium releases should also be taking advantage of chocolatey's prelease/beta functionality. This package should be kept in-line with the current release of chrome. All these nightly ("last known good build") builds should not be released as new package versions- they should be released as ${version}-beta.

Using beta for this package would be wrong, using -snapshot would be more correct, or -alpha or something along those lines.

[AeliusSaionji]

While chromium should be a usable browsers, it is less featured than other browsers that are based on chromium (Say: Google Chrome, Opera, Vivaldi, etc...).

My understanding is that chromium is only the parts of chrome that are open source. Chromium under Linux has all of the components I've mentioned (widevine provided as a separate installable package). Under Linux, chromium is as fully capable as chrome- it's just that Google isn't building it that way for Windows.

I know we prefer 1st party builds, but in this instance we have the misfortune of a 1st party who isn't interested in distributing chromium with all the functionality turned on.** Keep in mind Google doesn't compile chromium for Linux, either. Someone else, the package maintainer (a "3rd party") does.

Unfortunately, that is the only ones we can get using the API we currently use (from https://chromium.woolyss.com/,

If we make an exception for this package re: "3rd party", this is an easy fix.

Using beta for this package would be wrong

Neat, I was unaware that we had more granularity than just beta.

** Another potential explanation is that WebRTC and so on are not available through redistributable open source libraries under Windows. @woolyss might be able to shed light on that.

[AdmiringWorm]

My understanding is that chromium is only the parts of chrome that are open source.

That's actually my understanding as well.

Chromium under Linux has all of the components I've mentioned (widevine provided as a separate installable package).

I didn't know that (been a while since I last used linux now, my linux laptop is begging to be used though XD), anyways is that true for all distros. I know the Arch Linux distro chromium package is well structured thanks to some additional downloads and/or patches,

it's just that Google isn't building it that way for Windows.

True, there was even a time they didn't provide binaries at all for windows, as it was meant for developers only.

I know we prefer 1st party builds

It's not that we actually prefer. The binaries can come from another location, but they need to be verified to be the same as the binaries provided by the official location (to be allowed on chocolatey, unless I've misunderstood something).

Keep in mind Google doesn't compile chromium for Linux, either.

That is true, but also keep in mind that the packages provided on all linux distros have been compiled from the official source archives (with additional changes on some/most distros).

If we make an exception for this package re: "3rd party", this is an easy fix.

I personally would love to make an exception, but I would need confirmation from @ferventcoder and @gep13 before I would be confident enough to use 3rd party binaries.

Neat, I was unaware that we had more granularity than just beta.

More or less anything can be used in the pre-release part of the version (except it can't start with numbers, or dashes. It can't end with dashes either I believe (Nuget V2 rules)).

** Another potential explanation is that WebRTC and so on are not available through redistributable open source libraries under Windows. @woolyss might be able to shed light on that.

It would be awesome if he could shed some light on that, but I'm guessing he is quite busy, so he may not have the time to explain. (still crossing my fingers though)

[RedBaron2]

@Link-Satonaka said:

The current usage of the chromium package is not what one would expect when installing chromium.

What would you expect when installing chromium?

I will quote from the Chromium Projects Download Chromium page

Chromium builds do not auto-update, and do not have symbols. This makes them most useful for checking whether a claimed fix actually works.

@Link-Satonaka said:

It currently follows "last known good build" and also lacks WebRTC (H.264), widevine (Netflix), and syncing functionality.

The current Chromium package doesn't follow _"last known good build"_ or even LKGB. It follows the end of the day progress of the 'The Chromium Authors.' It lacks Sync, WebRTC, and Widevine because of licensing issues.

@Link-Satonaka what you seem to want in Chromium is what is already available in the Canary version of Chrome. The Canary version has

• Sync
• WebRTC
• Widevine
  Already baked in and vetted by Google to work.

This is a Quote from Google's Canary Website:

Google Chrome Canary has the newest of the new Chrome features.
Be forewarned: it's designed for developers and early adopters, and can sometimes break down completely.

I'm willing to help @AdmiringWorm change over to the other API , but I will mention that most of those builds it lists are already for things like

• Canary
• Dev
• Canary_asan
• Stable
• Beta
  These are already lines of Google Chrome Browser.

I need to PR changes to the Chromium package to make use of Chocolatey package parameters, but do to other issues IRL. These are on the back burner for now.

I will end my comment on this note. Everyone is entitled to their opinion. Enjoy the Weekend 😄

[AeliusSaionji]

What would you expect when installing chromium?

Let's put all the details aside- the answer to this question is the only part that is important.

I expect to get FOSS chrome (lacking a few things I didn't want anyway). Under Linux, this is exactly what I get.

With that expectation in mind, what do we have to do to make it work for Chocolatey/Windows?

It lacks Sync, WebRTC, and Widevine because of licensing issues.

How are sync and WebRTC done under Linux, then?

what you seem to want in Chromium is what is already available in the Canary version of Chrome

I explicitly do not want the google update service and other junk, actually. I don't necessarily want canary builds either- I want stable releases of chromium (FOSS)

[AeliusSaionji]

The actual differences between chrome and chromium are stated here:

https://en.wikipedia.org/wiki/Chromium_(web_browser)#Differences_from_Google_Chrome

The most significant item I can identify is a lack of bundled H.264 (something that Linux packagers overcome).

The lack of Sync and RTC is not inherit to chromium, just the google provided Windows builds.

[RedBaron2]

@Link-Satonaka
I will talk with @woolyss about using his API for Nik builds; if this will work for you?
The current package without a definitive answer from @gep13 or @ferventcoder will probably continue to be a Chromium Authors only package. The choice to make a new package of (ex: Chromium-Nik) would possibly solve your concerns/issues. They would have all the items on your wishlist, including a stable build, and soon to be installable with Chocolatey.

[AeliusSaionji]

I would personally appreciate the chromium-nik package, yes, but (with the approval of gep/ferventcoder) my chief concern is improving the chocolatey repo. As I see it, when a user goes to install the chromium package, they should get the same experience they would get under Linux, or as near to it as we can provide. I'm not a fan of diluting the chocolatey repo, and the user experience, with things like the-real-chromium-pkg-you-were-looking-for-but-with-an-arbitrary-name-because-it-was-compiled-elsewhere. The same problem exists with vim and my vim-tux package, actually.

If gep/ferventcoder not approve of the idea of using 3rd party builds, maybe the answer is that chocolatey maintainers begin compiling certain packages for the chocolatey repo.

[AdmiringWorm]

If gep/ferventcoder not approve of the idea of using 3rd party builds, maybe the answer is that chocolatey maintainers begin compiling certain packages for the chocolatey repo.

That would still not be the right thing, let me quote the moderation documentation the mods need to follow:

If it is a download, is it getting it from the proper location? Use the project site (projectUrl) to determine where the download for the file is coming from and it should match the one in the package files. If not there needs to be a really, really good reason for not doing so.

while it's a good reason to add codecs, the question is: is it good enough to approve it on chocolatey.org?

Anyways, one thing I think I forgot to mention on the topic of stable releases, if we are to change to only support stable releases (or additionally non-stable releases with the tag -snapshot) this would mean there won't be another update of chromium until the stable release version is above the currently available release on chocolatey.org (I think the current snapshot is 61.0.3115.0 while the latest stable is 58.something)

I'm willing to help @AdmiringWorm change over to the other API , but I will mention that most of those builds it lists are already for things like

I would very much appreciate that, as I haven't had enough time lately to do much when it comes to chocolatey packages.

[AeliusSaionji]

That would still not be the right thing, let me quote the moderation documentation..

My suggestion is a radical shift in the way chocolatey normally operates- I wouldn't expect the documentation to have any insight here.

My suggestion is that, if "third party" builds are so frowned upon, a chocolatey-compiled build would be the next logical step to correct defunct first party builds (which are rare- the only ones I know of are this and vim). I recognize this would require some serious consideration for how to implement- chocolatey currently does not have any systems or conventions or guidelines in place for maintainers to compile software for the repo. But it is something to keep in mind as we discuss our options. This is not, after all, a concept foreign to package managers :)

there won't be another update of chromium until the stable release version is above the currently available release on chocolatey.org

Correct, we have some time to decide how to proceed. I knew that any fixes would take months to propagate when I created this issue.

is that true for all distros. I know the Arch Linux distro chromium package is well structured thanks to some additional downloads and/or patches,

I missed this earlier. Yes, it is true of most. Some distros don't even offer Chrome. Linux people like their FOSS.

[woolyss]

Hello everybody,

@AdmiringWorm : Unfortunately, that is the only ones we can get using the API we currently use (from https://chromium.woolyss.com/, I'm considering a change to https://omahaproxy.appspot.com/ though which then would allow us to provide only stable releases)

https://omahaproxy.appspot.com/ is only for Google Chrome versions. You can also find them at https://sites.google.com/a/chromium.org/dev/getting-involved/dev-channel

Do you know I can share to you an API about all Chromium versions there are on my website (https://chromium.woolyss.com/) + ungoogled-chromium. It is already and used by few tools like chrlauncher (Chromium updater/launcher with a GUI).

@Link-Satonaka : Another potential explanation is that WebRTC and so on are not available through redistributable open source libraries under Windows

The WebRTC project is included in the <chromium>/src/third_party/webrtc directory so it is available. But Chromium is not a final project. Basically, it is the development browser of Google Chrome. That's why few important open-source projects (like WebRTC, Widevine, Sync...) are not implemented by default. This is not a licence issue. Check WebRTC licence at https://webrtc.org/license/software/

@Link-Satonaka : I will talk with @woolyss about using his API for Nik builds; if this will work for you?

Sure I can improve my API! ;)

[AeliusSaionji]

fwiw, I wrote an update script that just polls the github repository for Nik builds. It seems to be using the "latest release" tag for the release that aligns with chrome stable.

check it out here. the sooner we integrate a solution, the sooner the chromium package can stop updating until stable-version catches up...

https://github.com/Link-Satonaka/chocopkgs/blob/master/chromium/update.ps1

[ddhelmet]

Yeah if the chocolatey would install the current stable version it would make much more sense.

[AdmiringWorm]

@AeliusSaionji Sorry, I must have missed your comment somehow.
We would love a PR to add something like this, if you have the time.

@woolyss Apologies that I missed your comment as well

https://omahaproxy.appspot.com/ is only for Google Chrome versions. You can also find them at https://sites.google.com/a/chromium.org/dev/getting-involved/dev-channel

True, it is only for Google Chrome versions, but correct me if I'm wrong. Don't the version used with chrome actually match the version from chromium?

Do you know I can share to you an API about all Chromium versions there are on my website (https://chromium.woolyss.com/) + ungoogled-chromium. It is already and used by few tools like chrlauncher (Chromium updater/launcher with a GUI).

Ah, I didn't actually know that, using that API, is there any way to differentiate between nightly/dev builds and Google Chrome/Stable builds?

[woolyss]

@AdmiringWorm : Read https://github.com/chocolatey/chocolatey-coreteampackages/pull/875 of @AeliusSaionji. All is clear! ;)

Note that Nik - (@chrme) the developper of STABLE versions on Windows - compiles sometimes experimental builds. So make sure your "updater engine" is correct and checks the Github text/API content. In general, it is for DEV builds, not about STABLE builds. But he is a developper... ^^

Nik compiles a new STABLE Chromium build just after Google Chrome release. It can takes 1 day or more.
It is similar on other plateforms (Mac, Linux, BSD...)

[ddhelmet]

Any updates on this? Someone made a chromium-stable package last week using stable-sync build of https://github.com/henrypp/chromium/releases/
Will the official chromium package use woolyss builds in the near future?

[AdmiringWorm]

@ddhelmet a PR was opened here to add this, however we are waiting on an update from @AeliusSaionji regarding it.

[RedBaron2]

I will work on adding a chromium_snapshots if anyone wants it. First attempt was a wash. If anyone wants the package. I will work on adding to this repository.