Mailing-List: contact ooo-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: ooo-dev@incubator.apache.org
Received-SPF: neutral (athena.apache.org: 98.139.91.204 is neither permitted
 nor denied by domain of kay.schenk@gmail.com)
Message-ID: <4F85E976.3040904@gmail.com>
Date: Wed, 11 Apr 2012 13:28:38 -0700
From: Kay Schenk <kay.schenk@gmail.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US;
 rv:1.9.2.28) Gecko/20120306 SUSE/3.1.20 Thunderbird/3.1.20
MIME-Version: 1.0
To: ooo-dev@incubator.apache.org
Subject: Re: Linux builds
References: <4F816821.2030903@gmx.net> <4F816AAE.2080700@googlemail.com>
 <CALcb3vJ8DCF+aEKGWRRky=aydAzTkEe0qHTse3SqX14dHKQa7Q@mail.gmail.com>
 <20120408233105.GA2885@localhost> <4F82B706.9030509@googlemail.com>
 <20120409231246.GA29666@localhost> <4F84E50F.7040804@a-w-f.de>
 <20120411121814.GA11543@localhost> <4F859905.8040308@googlemail.com>
In-Reply-To: <4F859905.8040308@googlemail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit


On 04/11/2012 07:45 AM, � wrote:
> 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]

Ariel --

Well...my "kde integration" seems to be provided in:

openoffice.org3.4-suse-menus-3.4-9590.noarch.rpm

from the desktop-integration directory using the older kde3 integration 
which works just fine. But maybe this is referring to is some older 
holdover that is no longer viable.

>> 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?

none from me since I have little experience in this area...:/

I still wouldn't be in favor of holding up the release based on this 
issue though. But, up to others to implement this change and test. I no 
longer have the old 3.3 available to use for this.

>
> Juergen
>
>
>

-- 
------------------------------------------------------------------------
MzK

"Women and cats will do as they please,
  and men and dogs should relax and get used to the idea."
                                     -- Robert Heinlein