incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ariel Constenla-Haile <>
Subject Re: Linux builds
Date Wed, 11 Apr 2012 12:18:14 GMT
Hi Andre, *

On Wed, Apr 11, 2012 at 09:57:35AM +0800, Andre Fischer wrote:
> >>Does anybody have tested an upgrade installation with these new
> >>Linux packages and can verify the reported problem, see
> >>
> >>
> >>I think we haven't noticed this problem before and I would be
> >>interested if others can confirm this problem.
> >>
> >>I will be offline for ~1 day because of traveling and I will make
> >>the call for VOTE depending on the feedback from you.
> >
> >Old basis package set remaining is the default behaviour, at least
> >tested with OOo 3.0.0. On Fedora 16:
> >
> >- install OOo 3.0.0 (OOO300_m9 9358)
> >- install OOo 3.1.1 (OOO310_m19 9420)
> >
> >1) there is an issue with the desktop integration, same for AOO
> >2) the old basis3.0 remains:
> >
> >/opt/
> >/opt/
> >
> >All ooobasis3.0 packages are kept.
> Strange.
> Here is what I would expect would happen on an update:
> - There is one top-level or meta package that has dependencies on
> all the other packages (directly or indirectly)
> - This meta package of OOo3.? is replaced by AOO3.4
> - The packages of OOo3.? are not referenced anymore and get removed
> automatically.  The new packages are installed.  Everything is find.
> So one of the following things goes wrong:
> - The old meta package is not removed because the new one has no
> relationship to it (maybe because of a different application name)
> - The old meta package is removed but some other package keeps a
> reference to one of OOo3.? base packages.
> - Something else that I did not think of yet (I am currently on a
> business trip and am still adapting to the new time zone)

There are different issues.
The main one is that the package name containes %OOOBASEVERSION

Example: module = "gid_Module_Prg_Wrt_Bin"




I have installed following packages:

ooobasis3.4-writer   3.4.0-9590
ooobasis3.0-writer   3.0.0-9358
ooobasis3.1-writer   3.1.1-9420
ooobasis3.2-writer   3.2.1-9502
ooobasis3.3-writer   3.3.0-9567

Because the *package* name is different, they are indeed different
packages, ooobasis3.2-writer is *not* regarded as an update for
ooobasis3.1-writer, and so on.

ooobasis3.2-writer   3.2.1-9502 can only be updated by a package with
the same name, examples:

ooobasis3.2-writer   3.2.1-9503 (increase BUILD in

ooobasis3.2-writer   3.2.2-9502

Note that I'm not sure if this is an issue, or it is the way it was
designed with the idea of having different basis installations.
The only solution in this strange design is to declare a package
obsoleting the other ones, for example ooobasis3.4-writer obsoleting


This can be done using linuxreplaces in the files on
I've tried this is success (though minimal testing):

There are some caveats:

* A meta package is not enough, this has to be done on a per-packages
  way, not only to be in the safe side (if the user tries to install
  some package without the rest), but mainly because previous versions
  (and the current one) do not have a *real* meta package. The package
  openoffice.org3 gid_Module_Root_Brand does not provide every package
  OOo shipped in the tar file, see next point.
* gid_Module_Root_Brand requires

  When you install openoffice.org3 from AOO 3.4.0 over openoffice.org3
  from 3.3.0, it only gets updated because they have the same name.  It
  also updates the URE (due to same name, too).  It installs basis
  core01-07 and basis images, but does not update/remove previous
  packages because the name is different.  Besides, this sort of meta
  package does not install the office modules (writer, calc, etc).

* Apache OpenOffice orphans some packages that are no longer present:
  In the basis layer:
    kde-integration [yes, AOO has no KDE integration]
  In the brand layer, OOo 3.3 installed by default 3 dictionaries:
  These can all be obsoleted in openoffice.org3

In short, gid_Module_Root_Brand can be made a real meta package,
and linuxreplaces is the only solution to remove old basis packages.
(I still didn't look at the desktop integration package issue)

Ariel Constenla-Haile
La Plata, Argentina

View raw message