On 02/11/2019 01:39 AM, Douglas R. Reno via blfs-dev wrote:
On 2/11/19 1:31 AM, Ken Moffat via blfs-dev wrote:
In the thread 'firefox and libvpx' Bruce noted that firefox-65.0
failed to build with libvpx-1.8.0. I had earlier been looking at
current 66.0beta (b6) [ albeit without managing to build it ] and
there the test is similarly for >= 1.7.0. So I've removed that
recommended dependency and commented the item in mozconfig with an
explanation.
But this makes me wonder if we should drop most of the system libs
from firefox ?
When I started, systms were small and using the system libraries
seemed a good idea. There were also reports of problems if firefox
used its own sqlite3 and the system had a different version.
Since then, we have improved our handling of ca-certificates, so
continuing to use (latest) system nss and nspr seems like a good
idea - I think that if hte shipped versions are used, only the
upstream certificates available when the release was cut will be
used - so no changes and no local certs.
But beyond that, I start to think that times have moved on:
Chromium took a lead in forking local copies of everything, and to
an extent firefox has fallen into a similar approach (local copies,
not always forked, but not necessarily using pkgconfig to pull the
correct headers).
I guess things started to go downhill when I persuaded the other
editors that we should use the apng patches for libpng, in the
mistaken belief that other distros would do the same.
That was in the days when '/' could be small, and firefox could be
compiled in small amounts of RAM. Nowadays, doing this in systems
smaller than 20GB, or with less than 8GB of RAM, is unpleasant.
In more recent times we have lost the ability to use system cairo
(first it failed to build, then the option was removed).
So, I personally think that we should perhaps drop (from firefox)
the following system libraries:
icu,
libpng,
libvpx
and I am inclined to drop the system versions of:
libevent,
libffi,
libwebp,
libpixman.
Also, of course, drop the patch for system graphite2 and harfbuzz.
I guess that we can probably continue to use system bz2, jpeg,
sqlite, zlib without any problems.
Dropping the apng patch would also mean dropping system libpng from
seamonkey and thunderbird.
Thoughts ?
Note that I have not measured the changed time/space with firefox
dropping system libvpx, nor with dropping those I mentioned above.
But since its 'mach' build system gives variables times on
subsequent runs, and also slightly different space usage (also noted
in thunderbird when I looked at it after Douglas had problems), I
suspect that although the space and SBUs might increase a little, it
will not be a big deal.
ĸen
Hi ken,
To be honest, I'm against dropping system libraries. I like to patch
them whenever possible to work with Firefox. I think this comes from
having to deal with system-library problems in WebKit, and also the
possibility of having unknown vulnerabilities in the shipped copies of
libraries.
A recent example I can think of is the sqlite vulnerability, which isn't
fixed in Firefox's shipped copy. I'm inclined to believe that dropping
system pixman would cause problems as well with GTK+.
Part of me also feels as though dropping system libraries makes it
closer to a binary - which is something I'm certainly against.
I think staying on the present course is our best bet to be honest. As
for libevent, libwebp, libffi, and pixman - I think those would stay in
the same category as the "probably continue to use" pile because they
change so little.
I don't think using shipped copies of libraries is a good idea though. I
think we should use system copies unless we can absolutely avoid it.
Historically I think that the editors as a whole shared an opinion that
system libraries should be used whenever possible, but my memory is
quite foggy and it's been so long that I can't remember properly.
I am on the fence about using system libraries. On one hand, there may
be vulnerability fixes in the system libraries that are not in the
included libraries. On the other hand, changes to the system libraries
may interfere with building.
The vulnerability issue can be mitigated by the fact that FF may not
actually be using the part of the code that is problematic.
In any case, I'd like to delay any changes like this until after we
release 8.4 in a little over two weeks.
-- Bruce
--
http://lists.linuxfromscratch.org/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
