and linux distributions chromium · chromium: why it isn't in fedora yet as a proper package...
TRANSCRIPT
Chromiumand Linux Distributions
Paweł Hajdan, Jr.
https://www.flickr.com/photos/mtaphotos/6483098881
Chromium: Why it isn't in Fedora yet as a proper package (2009)
● not stable● forked libraries
not stable
● no releases○ first one in May 2010
● code pulled from SVN○ source tarballs on GS since 2011 (190 - 250 MB)
● remerging patches○ upstream your patches
● two days of work○ ~ half an hour with almost no patches
forked libraries (1 / 3)
● no “system libraries” on Windows or Mac
● diligent about third_party directories○ compare to e.g. media/libopus in Firefox○ allows whitelist-based removal of third party code
forked libraries (2 / 3)
● system libraries not supported by upstream○ not a problem in practice
● rebuttals Tom heard are just opinions○ “we move too fast”○ “we need specific version”○ also, e.g. sandbox support
forked libraries (3 / 3)package Chrome Gentoo stable
jinja 2.7.1 2.7.3
libevent 1.4.13 2.0.21
libpng 1.2.45 1.2.51 / 1.6.12
libxml 2.7.7 2.9.1
zlib 1.2.5 1.2.8
notable bundled libraries
● ffmpeg● hunspell● mesa● sqlite
ffmpeg
● moves too fast● Chromium developers work with upstream● technically could work
hunspell
● incompatible fork● changed dictionary format (bdict)● other changes, some upstreamed● upstream somewhat slow to respond● why CVS?
mesa
● incompatible fork● type mismatch on 32-bit
○ typedef ptrdiff_t GLsizeiptr; (GL/glext.h)○ typedef signed long int khronos_intptr_t; (khrplatform.h)
● why not glew?○ no support for GLES2○ no support for Chromium extensions○ was in fact using glew, although patched
sqlite
● incompatible fork● changed os_unix.c for sandboxed WebSQL● Chromium unlikely to do specific VFS● sqlite unlikely to make changes● WebSQL deprecated but still used
libraries not designed for reuse
● JS libraries like polymer, jszip● ASM bits e.g. x86inc● libyuv, skia, qcms, webrtc● libwebm
libraries that need more work (1 / 2)
● iccjpeg○ lcms and libjpeg-turbo don’t want it
● libsrtp○ need to update upstream copy, release & test
● libvpx○ needs to make a release
libraries that need more work (2 / 2)
● libusb○ discussion on upstream ML
● opus○ audio classifier not part of public API
notable unbundled libraries● bzip2● flac● harfbuzz● icu● jsoncpp● libevent● libjpeg● libpng● libwebp
● libxml● libsxlt● minizip● protobuf● re2● snappy● speex● zlib
enter build/linux/unbundle
● created in 2013● used by Arch, Gentoo, BSDs● easy to make changes
remove_bundled_libraries.pybuild/linux/unbundle/remove_bundled_libraries.py \
'third_party/ffmpeg' \'third_party/hunspell' \'third_party/leveldatabase' \'third_party/mesa' \'third_party/trace-viewer/third_party/jszip' \'third_party/trace-viewer/third_party/tvcm/third_party/polymer' \
--do-remove || die
FYI in Gentoo this has almost 100 lines.
generate_shim_headers.py (1 / 3)
#include "third_party/libpng/png.h"
can’t change that line!
what now?
generate_shim_headers.py (2 / 3)out/Release/gen/shim_headers/libpng/target
└── third_party
└── libpng
├── pngconf.h
└── png.h
#include <png.h>
generate_shim_headers.py (3 / 3)
● can use #pragma push_macro○ e.g. POSIX -> POSIX_SYNTAX in re2
● can use #include_next○ was used for system mesa (infinite recursion)
● can include additional headers before / after○ keep additions separate, e.g. Chromium extensions
replace_gyp_files.py{ 'targets': [ {
'target_name': 'libpng', 'type': 'none',
'dependencies': [ '../zlib/zlib.gyp:zlib', ],
'direct_dependent_settings': { 'cflags': [ '<!@(pkg-config --cflags libpng)', ], },
'link_settings': {
'ldflags': [ '<!@(pkg-config --libs-only-L --libs-only-other libpng)', ],
'libraries': [ '<!@(pkg-config --libs-only-l libpng)', ],
},
'variables': {
'headers_root_path': '.',
'header_filenames': [ 'png.h', 'pngconf.h', ],
},
'includes': [ '../../build/shim_headers.gypi', ],
}, ], }
contributions are welcome
● 2382 unique committers, 53 unique domains○ 1806 @chromium.org○ 638 @google.com○ 157 @gmail.com○ 123 @samsung.com○ 64 @intel.com○ 63 @opera.com○ 28 @yandex-team.ru○ 13 @motorola.com
contributions are welcome
● Google CLA is not a copyright assignment○ Compare to Fedora Project Contributor Agreement
● some FreeBSD / OpenBSD bits upstreamed● MIPS bits upstreamed● Wayland/Ozone using a hybrid approach● often just need bandwidth
https://www.flickr.com/photos/mtaphotos/6483098041
