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
Using the autocorrect list of LibreOffice
extras/source/autotext/lang/en-US/acor/DocumentList.xml
Change-Id: I8b93969bc0742c2e95b8b7db3c4c37691e8d3657
Script: http://pastebin.ca/2327716
It was never integrated and used. If we made the effort to integrate it,
Windows installer would be a few megabytes smaller, because indexes of
thesauri would be generated in install time (instead of packaging
pre-generated indexes).
However, the cons are:
* untested
* presumably slows down instal process which is slow already
* adds complexity to installer which is too complex already
* indexes will not be there in case of administrative install (QA)
* bad experiences with CustomActions that manipulate the installed
application (various, weird permission problems)
Change-Id: I3989b835b1250718bc03107a3807d091e7a9aa0e
The main goal of this patch was to simplify things. The LibreOffice
version that goes to Intel AppUp use advertsied shourtcuts, because
it is what Intel AppUp Center requires. We can reduce complexity a
bit, if we use advertised shortcuts in normal builds, too.
Change-Id: Ia35a753c83cb592137232428ab897a640e7ccc1f
It is not entirely clear what this CustomAction was supposed to do, but
program\edition directory is not present in LibreOffice, therefore this
feature is useless.
Change-Id: Icfcd9c5f88da28e171329d951956baaa42908fd0
It copied *.oxt from [SourceDir]\extension to TARGETDIR\share\extension\install.
One might think that *.oxt files there get installed automagically at first start,
but no, it does not happen. This feature looks useless.
Change-Id: I5ce583f3b46f5e4e962449790bdce70f99aa135b
I think this CustomAction is unnecessary, providing that we do
not use Star Division home-made PATCH technology. I have never
seen this CustomAction used in any OpenOffice.org/LibreOffice builds.
Change-Id: I62f3b5a3ef8a9686f018ca1af52689954262e830
And did it also for GetMsiProp() and *MsiProperty()
Reworked some conditions related to that.
Change-Id: I1cd082361126db3d9aced3a878b19e7052514864
Reviewed-on: https://gerrit.libreoffice.org/1816
Reviewed-by: Andras Timar <atimar@suse.com>
Tested-by: Andras Timar <atimar@suse.com>
For Windows, superseded by Windows Installer patching (i.e., creating
.msp files), which is something completely different. (And quite hard
to get working... but still a saner approach, I think.)
For Linux, many distros use delta RPMs or similar, so no home-grown
LO-specific patching mechanism is needed.
Remove the -patch and -patchinc command-line options to
make_installer.pl and all code that was invoked only when using those.
Remove the PATCH and PATCH_ONLY flags in scp2.
Remove the patchmsi.dll Windows Installer custom action.
Change-Id: I09e949e601a969f88eff60067faa2352f4f89537
Reviewed-on: https://gerrit.libreoffice.org/1605
Reviewed-by: Michael Stahl <mstahl@redhat.com>
Tested-by: Miklos Vajna <vmiklos@suse.cz>
GUI only takes values UNX or WNT, so it is fairly pointless. One can check
whether OS is WNT or not instead.
Change-Id: I78ae32c03536a496a563e5deeb0fca78aebf9c34
Reviewed-on: https://gerrit.libreoffice.org/1304
Reviewed-by: Peter Foley <pefoley2@verizon.net>
Tested-by: Peter Foley <pefoley2@verizon.net>
...as gm_Langpack_r_en_US was explicitly excluded from langs[] in
SelectLanguage, so addMatchingDictionaries was never called for it. (This was
only evident in installation sets conaining only few langpacks, as the
"official" multi-lang installation set also contains en_GB etc., so appropriate
dictionaries were selected through those.)
Reworked the logic of chosing which langpacks to preselect (see the comment in
SelectLanguage); hope it still works as intended for the various cases (of which
the "official" multi-lang installation set is the only truly relevant one, for
now).
Change-Id: I31f531194c79e49c9c09e33454a7b0a82d9ff02f
I don't think it made sense to check OpenWithList at all. When we
found WordPad there, we registered the file type, even when it was
registered by MS Office.
Change-Id: I15a151051cadd329e8614388ceb84470ea28805a
Now that 5c47e5f63a79a9e72ec4a100786b1bbf65137ed4 "fdo#51252 Disable copying
share/prereg/bundled to avoid startup crashes" removed the use of share/prereg,
there is no longer need to generate it in the first place (by calling "unopkg
sync" at build or installation time), and so no need for the "unopkg sync" sub-
command, either. This also allows to simplify some of the jvmfwk code that was
only there so that "unopkg sync" (which can require a JVM) can work in "hostile"
environments (during build and installation).
Change-Id: I52657384f4561bf27948ba4f0f88f4498e90987f
Transforms currently cannot be generated as Wine does not implement
MsiDatabaseGenerateTransform().
Change-Id: I03507e07f372871eed23ac932426d5708f765884
Signed-off-by: Fridrich Štrba <fridrich.strba@bluewin.ch>
