This has never been enabled during the open source history of
openoffice.org . Yet we have been building the code and the resource
file for it. Should I be surprised?
Change-Id: Iba8262f125d0ea3a35fa7f256a3cdbd353e598bc
math.dtd was dropped from installation in 2009, see
https://issues.apache.org/ooo/show_bug.cgi?id=97200#c3 :
"In agreement with MIB and MT it was diecided that the Math.dtd should
be removed from the installation set as well since it
a) has incorrect content
b) is no longer used nowadays at all"
Change-Id: Id2a727338c224b0beb4b8def197988ab071a7d94
The FILELIST install method is really tailored to large sets of closely
related files. It is not such a great idea to apply it just to move some
unrelated files, delivered from a single module, out of $(OUTDIR), like
here, because it requires splitting one Package to several to allow the
files to be placed to different installation modules in scp2. The extra
makefile increases the overhead needed to place a file into an
installation set. We really need a better way to handle this...
Change-Id: I2f271562d8773152e69d284b4fe8ae356dea0945
Do we need to install them? Or even have them in the sources, FWIW? The
old XML format has been superceded by ODF 10 years ago...
Change-Id: I909afcf86ae808441c7dbc6182512bedb9789c1c
This also reinstates the use of brand_dev/intro.png for non-release
builds, lost with gbuildization of instsetoo_native (commit
1d84e9d1d3).
Change-Id: I43477505c5c9a3d6ec961d640608e6e91379868e
See developer mailing list for discussion, subject "LibreOffice is one or
several applications?"
Change-Id: I7a4a5a76f980eb458a2b6d4558a553b8508fd990
Reviewed-on: https://gerrit.libreoffice.org/3638
Reviewed-by: Tor Lillqvist <tml@iki.fi>
Tested-by: Tor Lillqvist <tml@iki.fi>
OLDPRODUCT2 - it was a workaround for OOo 1.9, obsolete
SAMEPRODUCTS - same product have the same ProductCode, so installer detect it
anyway under normal circumstances. It is possible that a tester/developer tries
to install the same version with different ProductCode over an existing installation
(e.g. dailyes or RCs). Then we are in trouble. However, SAMEPRODUCTS was not in use.
Moreover, Windows Installer uses only the first three fields of the product version.
So we cannot make difference between e.g. 4.0.3.1 and 4.0.3.2, and this is the new versioning
scheme.
BETAPRODUCTS - LibreOffice have never used different upgrade code (BETAUPGRADECODE) for betas.
OLDPRODUCTSPATCH, SAMEPRODUCTSPATCH, NEWPRODUCTSPATCH - related to old Star Division patching
mechanism, they were commented out anyway.
STUBPRODUCTS, STUBUPGRADECODE - these look useless
Change-Id: I77d67b72e18fa6b3ba4182b99e198c42f247cea4
IMHO there is no reason why they should be 0444. I have found no
explanation for it, either in the commit that introduced the bundled
dictionaries or in the related bug.
Change-Id: Ia42218a0d579ced5f17248a092eab2c61cb9005f
These are put into uno_loader_classes.zip, which is then not used at
all, and odkcommon.zip, which is used for creation of install sets.
Seriously?!
Change-Id: I28b5bc73857cf524fb12f7918acd2891ff12d166
What is a little confusing is that the udkapi.rdb ends up as types.rdb in the
installation set (in the URE's sub-tree). So all places that reference it
during the build do so as "udkapi" while all places that reference it in an
installation set do so as "types."
Change-Id: I35d0695966b3bd703f5494b636b9782efc0d3fcb
