At least for Linux RPM, the packages built via EPM in module instset_native
(with --enable-epm) record intra-installation-set dependencies only by name but
without any version numbers, so that one can e.g. freely ask rpm to install a
(broken) combination of packages from LibreOffice_4.0.2_Linux_x86-64_rpm.tar.gz
and LibreOffice_4.0.3_Linux_x86-64_rpm.tar.gz.
The documentation for EPM (e.g., workdir/*/UnpackedTarball/epm/doc/epm-
manual.pdf) states that %requires lines can optionally indicate lower and upper
version numbers, so the easiest fix appears to be to augment all relevant
"requires =" lines in setup_native/source/packinfo/packinfo_*.txt with lower ==
upper == %PACKAGEVERSION. (There appears to be some confusion in those files
between %PACKAGEVERSION and %ABOUTBOXPRODUCTVERSION, but those seem to always
get identical values in instsetoo_native/util/openoffice.lst.in.)
Change-Id: Iea68beb19f1699cc1eea3dc36fd2f11b8845e390
TODO: The freebsdrequires and solarisrequires lines are not updated.
Reviewed-on: https://gerrit.libreoffice.org/4344
Reviewed-by: David Tardon <dtardon@redhat.com>
Tested-by: David Tardon <dtardon@redhat.com>
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
...at least due to dependency of librelogo.xcd on writer.xcd, see
82c53d537a05dadf4d7fd7ea41292897bf2d47c7 "Missing dependency."
Otherwise, having librelogo installed but not writer will cause an uncaught
RuntimeException from configmgr::Components::parseXcdFiles
(configmgr/source/components.cxx) early on in soffice.bin.
Change-Id: I97565fe5c790ed182bb27fd722c650acf8a8ee08
Therefore we packed Aragonese dictionary into Spanish and Catalan
langpacks, instead of Spanish and Catalan dictionaries.
Change-Id: I6b7606b8d8f4f30cded583b96d9f9b5f2ef64e9f
Using the autocorrect list of LibreOffice
extras/source/autotext/lang/en-US/acor/DocumentList.xml
Change-Id: I8b93969bc0742c2e95b8b7db3c4c37691e8d3657
Script: http://pastebin.ca/2327716
The old version should get repalced by the ure package. It should also conflict
with the new ure package.
This commit adds support for %incompat epm tag. It produces conflicts in rpm
and deb. It can be defined in setup_native/source/packinfo by
linuxincompat.
This commit also removes obsolete hack for debian dependencies.
libreoffice-bundled conflict is mentioned in the desktop-integration package
these day. The hack in epmfile.pm was not used because no package
used "replace" tag.
Change-Id: I5e9cb89a6108c22c61287fce1ffc6baf3f618d15
Reviewed-on: https://gerrit.libreoffice.org/2260
Reviewed-by: Fridrich Strba <fridrich@documentfoundation.org>
Tested-by: Fridrich Strba <fridrich@documentfoundation.org>
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>
It was discovered that on a Russian Windows, by default only Russian and
German dictionaries would be installed, but no English dictionary. This is
because since e2fac98819c00b4fb50f9de9d0f32d20092f3191 "fdo#53009: For msi
installer, only default-select a subset of dictionaries" only those dictionaries
mentioned in setup_native/source/packinfo/spellchecker_selection.txt were
default-selected, but it apparently was a misunderstanding that
spellcheker_selection.txt for many locales does not list "en" even though an
English dictionary should always be default-installed.
Quoting Andras Timar <atimar@suse.com>: "AFAIK en-US localization with English
dictionaries is always installed in all 3 supported platforms by default. On
Windows default install should always select en-US and English dictionaries. If
it does not do so under certain circumstances, then it is a bug in my opinion.
We removed en-US entry from the spellchecker selection file for this very
reason. It would have only bloated Mac and Linux langpacks."
So this fix simply makes sure that "en" is included in every line of the
generated spellchecker_selection.hxx that is used by
setup_native/source/win32/customactions/sellang/sellang.cxx to determine which
dictionaries to select by default.
Change-Id: I3db68585dc6269a7db2f6cbf6b79796dc09d05e8
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>
Remove the oooblogger extension. It is unmaintained and the original
author (caolan) wants it dead.
Change-Id: Iff89f5badbb74f465c57e068a9e1acbbc13bc235
No need for dirty hacks linking in basegfx objects statically any more.
To avoid unnecessary confusion between the newly plain code and any instance of
the old extension still installed (per-user or shared), I renamed all relevant
UNO implementation identifiers from com.sun.star.comp.documents.* to
org.libreoffice.comp.documents.*. Also, existing installations of the extension
are explicitly not migrated to new user profiles.
The xpdfimport executable is now in program/, its xpdfimport_err.pdf in
share/xpdfimport/. To simplify finding the _err.pdf from xpdfimport, its full
pathname is now given as additional second argument to xpdfimport. To find
xpdfimport executable from CppunitTest, CppunitTest creates a symlink from
solver's unittest/installation/program to solver's bin, so that
"$BRAND_BASE_DIR/program/xpdfimport" works there (as CppunitTest now sets
BRAND_BASE_DIR to solver's unittest/installation).
The sdext/source/pdfipmort/dialogs/ Basic stuff appeared to be unused (even
though it was included in the .oxt) and has been removed.
The --disable-ext-pdfimport configure switch is renamed to --disable-pdfimport.
Having it still conditional requires some pdf_Portable_Document_Format vs.
pdf_Portable_Document_Format_import foo in module filter.
Change-Id: Iee58c2f6187142a418decc9ea3a5df10eb7e0523
