Icecat api
We talked about this at today's meeting but decided to defer it as there was a lot to think about. Latest discussion about this issue is old but conveys the idea of what developers think ( ). Build process considers system libraries linkage, but not for all.
#Icecat api archive#
Many other library source trees have been released in the Icecat source archive however various of them, like jpeg or zlib or libvpx and others, can be also not used. What is the attitude of upstream towards bundling? They are updated from subversion repositories used sub-version is indicated in the README_MOZILLA file. Is upstream keeping the base library updated or are they continuously one or more versions behind the latest upstream release? I don't understand fine what this question says, upstreams are active currently.Īre the changes useful to consumers other than the bundling application?
#Icecat api software#
The patches from are specific for the software (Firefox/Icecat) probably many of them had been even proposed and accepted by upstream.Ĭould we make the forked version the canonical version within Fedora? For instance, if upstream for the library is dead, is the package we're working on that bundles willing to make theirįork a library that others can link against? Instance, if upstream for the library is dead). Have the changes been proposed to the Fedora package maintainer for the library? In some cases it may make sense for our package to take the changes despite upstream not taking them (for Why haven't the changes been pushed to the upstream library? If no attempt has been made to push the changes upstream, we shouldn't be supporting people forking out of laziness. In this particular case (libvorbis), "some files are renamed during the copy to prevent clashes with objectįile names with other Mozilla libraries" as we can read in the README_MOZILLA file. For example, libvorbis sources are patched according to this bug ticket. They are copied from the subversion repositories by an "update.sh" script that considers the application of some patches. If the library has not been modified (ie: it can be used verbatim in the distro) there's little chance of an exception. Note > that fixing bugs is not grounds to copy. Has the library behaviour been modified? If so, how has it been modified? If the library has been modified in ways that change the API or behaviour then there may be a case for copying. According to the Packaging guidelines, it's possible an exception "when an application needs unreleased features of a library and that library has committed to those features". These libraries are libvorbis, libogg, opus, libtheora. GNUzilla IceCat web browser compilation doesn't consider linkage against some media libraries in Fedora.