incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jürgen Schmidt <jogischm...@googlemail.com>
Subject Re: Linux builds
Date Wed, 11 Apr 2012 14:45:25 GMT
On 4/11/12 2:18 PM, Ariel Constenla-Haile wrote:
> 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
>>>> https://issues.apache.org/ooo/show_bug.cgi?id=119162
>>>>
>>>> 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/openoffice.org/basis3.0
>>> /opt/openoffice.org/basis3.1
>>>
>>> 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"
> main/setup_native/source/packinfo/packinfo_office.txt#88
>
> packagename = "%BASISPACKAGEPREFIX%OOOBASEVERSION-writer"
>
> %BASISPACKAGEPREFIX -->  ooobasis
> main/instsetoo_native/util/openoffice.lst#20
>
> %OOOBASEVERSION -->  3.4
> main/instsetoo_native/util/openoffice.lst#7
>
> 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
> main/solenv/inc/minor.mk#23)
>
> ooobasis3.2-writer   3.2.2-9502
> etc.
>
>
> 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
>
> ooobasis3.0-writer
> ooobasis3.1-writer
> ooobasis3.2-writer
> ooobasis3.3-writer
>
>
> This can be done using linuxreplaces in the files on
> main/setup_native/source/packinfo/
> I've tried this is success (though minimal testing):
> http://people.apache.org/~arielch/packages/yum-update-fix.txt
>
> 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
>    %UREPACKAGEPREFIX-ure
>    %BASISPACKAGEPREFIX%OOOBASEVERSION-core01
>    %BASISPACKAGEPREFIX%OOOBASEVERSION-core02
>    %BASISPACKAGEPREFIX%OOOBASEVERSION-core03
>    %BASISPACKAGEPREFIX%OOOBASEVERSION-core04
>    %BASISPACKAGEPREFIX%OOOBASEVERSION-core05
>    %BASISPACKAGEPREFIX%OOOBASEVERSION-core06
>    %BASISPACKAGEPREFIX%OOOBASEVERSION-core07
>    %BASISPACKAGEPREFIX%OOOBASEVERSION-images
>
>    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:
>      oooimprovement
>      kde-integration [yes, AOO has no KDE integration]
>    In the brand layer, OOo 3.3 installed by default 3 dictionaries:
>      openoffice.org3-dict-en
>      openoffice.org3-dict-es
>      openoffice.org3-dict-fr
>    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)
>

Hi Ariel,

thanks a lot for this useful analysis and investigation in the problem.

The question now is if we should use this approach to extend the 
root_brand package to become a meta package to cleanly remove old 
packages. If the patch from Ariel works and we can test it quite fast it 
could be an option for now to improve the install user experience.

Any opinions?

Juergen




Mime
View raw message