I don't use chromium and I don't know what release cycle it has, but can't those interested in running chromium use an ebuild that tracks the git tree
and updates after every change.
The maintenance burden would be minimal, and any patches could be applied
with /etc/portage/patches.
If something like this isn't suitable for ::gentoo, it can be added to a personal overlay.
If the upstream release cycle is too fast, someone could fork the repo and update the fork as slow as desired.
Maybe something like this:
# Copyright 1999-2023 Gentoo Authors
# Distributed under the terms of the MIT License
EAPI=8
DESCRIPTION="The chromium browser" HOMEPAGE="
https://github.com/chromium/chromium" EGIT_REPO_URI="
https://github.com/chromium/chromium.git"
inherit git-r3
LICENSE="BSD-3"
SLOT="0"
KEYWORDS="~amd64 ~x86"
IUSE=""
DEPEND="|| ( sys-devel/gcc
sys-devel/clang )"
RDEPEND="${DEPEND}"
BDEPEND=""
src_configure() {
chromium_configure
}
src_install() {
chromium_compile
mv out/Release/chromedriver{.unstripped,} || die
rm -f out/Release/locales/*.pak.info || die
# Build manpage; bug #684550
sed -e 's|@@PACKAGE@@|chromium-browser|g;
s|@@MENUNAME@@|Chromium|g;' \
chrome/app/resources/manpage.1.in > \
out/Release/chromium-browser.1 || die
# Build desktop file; bug #706786
sed -e 's|@@MENUNAME@@|Chromium|g; s|@@USR_BIN_SYMLINK_NAME@@|chromium-browser|g; s|@@PACKAGE@@|chromium-browser|g;
s|\(^Exec=\)/usr/bin/|\1|g;' \
chrome/installer/linux/common/desktop.template > \ out/Release/chromium-browser-chromium.desktop || die
# Build vk_swiftshader_icd.json; bug #827861
sed -e 's|${ICD_LIBRARY_PATH}|./libvk_swiftshader.so|g' \ third_party/swiftshader/src/Vulkan/vk_swiftshader_icd.json.tmpl > \ out/Release/vk_swiftshader_icd.json || die
}
Also, with all this discussion, one can't help but wonder, is
firefox/librewolf also in such danger?
On Wed, Jun 7, 2023 at 7:49 PM Mike Gilbert <
floppym@gentoo.org> wrote:
On Wed, Jun 7, 2023 at 3:25 PM Jeff Gazso <jeff.gazso@gmail.com> wrote:
That does sound painful.
- Across the 3 channels, you are looking at roughly 12 releases per
month.
That's a lot of churn.
* Why build unstable stuff, why not build only stable releases and fix
the
problems once?
That's certainly an option. The downside is stable releases almost
always fix security issues, so you are "under the gun" at that point.
* Looking at chromium-browser-official and the GitHub mirror, it's
unclear to
me which release is stable. How is that sorted out?
Some links for you:
https://chromiumdash.appspot.com/releases?platform=Linux https://chromereleases.googleblog.com/
- Upstream likes to use modern C++ features, and they write C++ code
that
tends to break or is unsupported on stable releases of GCC and LLVM.
* How common of a problem is the C++ issue?
There are usually some issues with every major Chromium version.
* I don't know C++, is that a major obstacle?
Yes; you would at least need to teach yourself enough of the language
to attempt to interpret compiler error message.
- Upstream bundles many libraries. The Gentoo ebuild has some logic to unbundle a number of these, but maintaining it is a pain.
* What tends to go wrong?
- Version mismatches: upstream expects a different version of the
library than we have stable on Gentoo.
- Custom patching: sometimes Chromium forks/patches the bundled
library and there is a delay in sending those changes upstream (if it
ever happens).
- Chromium source files sometimes refer to the bundled header files
directly (#include "third_party/mylib/mylib.h") instead of using a
generic path like #include <mylib.h>.
- Using the bundled libraries sometimes is problematic, especially on non-x86-64 targets which upstream doesn't support well.
* What tends to break here?
For example, take ffmpeg. The bundled library uses a pre-configured
copy of ffmpeg, which can break depending on the user's system. At a
minimum, we need to reconfigure the bundled ffmpeg to work properly.
* Is the upstream likely to take patches or are we stuck maintaining a
patch
set for pretty much all non-x86-64 targets?
Upstream supports x86-64 and ARM only. All other targets require
distro patching.
* Is this why Sam maintains a bunch of PPC64 patches? Do these ever make their way upstream?
Yes, this is why we have a PPC64 patchset (which we mostly steal from
Raptor Computing).
<div dir="ltr"><div>I don't use chromium and I don't know what release cycle it has, but can't those interested in running chromium use an ebuild that tracks the git tree and updates after every change.</div><div>The maintenance burden would
be minimal, and any patches could be applied with /etc/portage/patches. <br></div><div>If something like this isn't suitable for ::gentoo, it can be added to a personal overlay.</div><div>If the upstream release cycle is too fast, someone could fork
the repo and update the fork as slow as desired.</div><div>Maybe something like this:</div><div># Copyright 1999-2023 Gentoo Authors<br># Distributed under the terms of the MIT License<br><br>EAPI=8<br><br>DESCRIPTION="The chromium browser"<br>
HOMEPAGE="<a href="
https://github.com/chromium/chromium">https://github.com/chromium/chromium</a>"<br>EGIT_REPO_URI="<a href="
https://github.com/chromium/chromium.git">https://github.com/chromium/chromium.git</a>"<br>inherit git-r3<br>
<br>LICENSE="BSD-3"<br>SLOT="0"<br>KEYWORDS="~amd64 ~x86"<br>IUSE=""<br><br>DEPEND="|| ( sys-devel/gcc<br> sys-devel/clang )"<br>RDEPEND="${DEPEND}"<br>BDEPEND="&
quot;<br><br>src_configure() {<br> chromium_configure<br>}<br><br>src_install() {<br> chromium_compile<br><br> mv out/Release/chromedriver{.unstripped,} || die<br><br> rm -f out/Release/locales/*.<a href="
http://pak.info">pak.info</a> || die<br><br> #
Build manpage; bug #684550<br> sed -e 's|@@PACKAGE@@|chromium-browser|g;<br> s|@@MENUNAME@@|Chromium|g;' \<br> chrome/app/resources/<a href="
http://manpage.1.in">manpage.1.in</a> > \<br> out/Release/chromium-browser.1 || die<br><br> # Build
desktop file; bug #706786<br> sed -e 's|@@MENUNAME@@|Chromium|g;<br> s|@@USR_BIN_SYMLINK_NAME@@|chromium-browser|g;<br> s|@@PACKAGE@@|chromium-browser|g;<br> s|\(^Exec=\)/usr/bin/|\1|g;' \<br> chrome/installer/linux/common/desktop.template &
gt; \<br> out/Release/chromium-browser-chromium.desktop || die<br><br> # Build vk_swiftshader_icd.json; bug #827861<br> sed -e 's|${ICD_LIBRARY_PATH}|./libvk_swiftshader.so|g' \<br> third_party/swiftshader/src/Vulkan/vk_swiftshader_icd.json.
tmpl > \<br> out/Release/vk_swiftshader_icd.json || die<br>}</div><div><br></div><div>Also, with all this discussion, one can't help but wonder, is firefox/librewolf also in such danger?<br></div><div><br></div></div><br><div class="gmail_quote"><
div dir="ltr" class="gmail_attr">On Wed, Jun 7, 2023 at 7:49 PM Mike Gilbert <<a href="mailto:
floppym@gentoo.org">
floppym@gentoo.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(
204,204,204);padding-left:1ex">On Wed, Jun 7, 2023 at 3:25 PM Jeff Gazso <<a href="mailto:
jeff.gazso@gmail.com" target="_blank">
jeff.gazso@gmail.com</a>> wrote:<br>
><br>
> That does sound painful.<br>
><br>
> > - Across the 3 channels, you are looking at roughly 12 releases per month.<br>
> > That's a lot of churn.<br>
><br>
> * Why build unstable stuff, why not build only stable releases and fix the<br>
> problems once?<br>
That's certainly an option. The downside is stable releases almost<br> always fix security issues, so you are "under the gun" at that point.<br>
> * Looking at chromium-browser-official and the GitHub mirror, it's unclear to<br>
> me which release is stable. How is that sorted out?<br>
Some links for you:<br>
<a href="
https://chromiumdash.appspot.com/releases?platform=Linux" rel="noreferrer" target="_blank">
https://chromiumdash.appspot.com/releases?platform=Linux</a><br>
<a href="
https://chromereleases.googleblog.com/" rel="noreferrer" target="_blank">
https://chromereleases.googleblog.com/</a><br>
> > - Upstream likes to use modern C++ features, and they write C++ code that<br>
> > tends to break or is unsupported on stable releases of GCC and LLVM.<br>
><br>
> * How common of a problem is the C++ issue?<br>
There are usually some issues with every major Chromium version.<br>
> * I don't know C++, is that a major obstacle?<br>
Yes; you would at least need to teach yourself enough of the language<br>
to attempt to interpret compiler error message.<br>
> > - Upstream bundles many libraries. The Gentoo ebuild has some logic to<br>
> > unbundle a number of these, but maintaining it is a pain.<br> ><br>
> * What tends to go wrong?<br>
- Version mismatches: upstream expects a different version of the<br>
library than we have stable on Gentoo.<br>
- Custom patching: sometimes Chromium forks/patches the bundled<br>
library and there is a delay in sending those changes upstream (if it<br>
ever happens).<br>
- Chromium source files sometimes refer to the bundled header files<br> directly (#include "third_party/mylib/mylib.h") instead of using a<br>
generic path like #include <mylib.h>.<br>
> > - Using the bundled libraries sometimes is problematic, especially on<br>
> > non-x86-64 targets which upstream doesn't support well.<br> ><br>
> * What tends to break here?<br>
For example, take ffmpeg. The bundled library uses a pre-configured<br>
copy of ffmpeg, which can break depending on the user's system. At a<br> minimum, we need to reconfigure the bundled ffmpeg to work properly.<br>
> * Is the upstream likely to take patches or are we stuck maintaining a patch<br>
> set for pretty much all non-x86-64 targets?<br>
Upstream supports x86-64 and ARM only. All other targets require<br>
distro patching.<br>
> * Is this why Sam maintains a bunch of PPC64 patches? Do these ever make<br>
> their way upstream?<br>
Yes, this is why we have a PPC64 patchset (which we mostly steal from<br> Raptor Computing).<br>
</blockquote></div>
--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)