incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kay Schenk <>
Subject Re: [UPDATE SERVICE] proposal a OOo 3.3 update service
Date Wed, 16 May 2012 19:58:22 GMT

On 05/16/2012 12:48 PM, Oliver-Rainer Wittmann wrote:
> Hi,
> On 16.05.2012 19:27, Kay Schenk wrote:
>> On Wed, May 16, 2012 at 4:24 AM, Oliver-Rainer Wittmann<
>>> wrote:
>>> Hi,
>>> as our release AOO 3.4 is out now for more than a week I think it would
>>> make sense to reactivate a simple update service for installed OOo 3.3
>>> versions.
>>> I have already seen a post on the users mailing list that the update
>>> functionality is not working in OOo 3.3. I assume that corresponding
>>> posts
>>> also exist in the forum.
>>> From my point of view it is time to let our OOo 3.3 users know via the
>>> update functionality that we have released AOO 3.4.
>>> The update URL for OOo 3.3 is:
>>> Update<>(plus
>>> a query part ?pkgfmt=<pkgformat> for non-Windows platforms)
>>> As this URL resolves to nothing, the user currently gets the following
>>> response from the update functionality in OOo 3.3:
>>> Status: Checking for an update failed.
>>> Description: Error reading data from the network.
>>> Server error message: Could not read status line: An existing connection
>>> was forcibly closed by the remote host.
>>> There are two solutions:
>>> (A) "static" solution:
>>> Provide an XML document similar to the one which is attached when an
>>> HTTP
>>> GET request to the above given URL is made.
>>> The attached XML document contains an atom feed according to [1]
>>> Currently, it only contains entries for:
>>> - German, Windows
>>> - German, MacOS X
>>> - German, Linux, 32bit
>>> - German, Linux, 64bit
>>> - English-US, Windows
>>> I hope I got the inst:os and inst:arch content right for all the
>>> platforms.
>>> For Windows and MacOS we could directly provide download links. Thus,
>>> the
>>> update functionality can download it and install it on corresponding
>>> user
>>> demand.
>>> For Linux we can not distinguish the different needed package formats in
>>> this "static" solution - as far as I know. Thus, a landing page can be
>>> given here. The update functionality can open it in the user's default
>>> browser on corresponding user demand. In the attached XML document I
>>> included our AOO 3.4 release announcement page as this landing page -
>>> this
>>> is only a proposal.
>>> The final XML document needs to be extended by entries for all possible
>>> combinations. This would mean 4 entries (Windows, MacOS X, Linux 32bit,
>>> Linux 64bit) for each language which we had released for AOO 3.4.
>>> It would be also be possible to include more combinations for which we
>>> have no package. We could create a special landing page for these which
>>> state that AOO 3.4 is out and that the user might want to have a
>>> look, if
>>> one of the provided packages would fit her/his needs.
>>> For this solution we need to provide the XML document at the above given
>>> URL.
>> Oliver--
>> Hi. OK, a dumb question...have you ascertained that this doc actually
>> works? That is, have you tested it with some sort of URL redirect?
> I am testing with my test XML documents on
> I am not using redirects. Instead I am adjusting my version.ini resp.
> versionrc files.
>> Right now, we have an area on the web server that could house
>> /projects/update36/ProductUpdateService
>> If you overwrite check.Update with this file, and do a local host setup,
>> your own /etc/hosts, and redirect to
>> you could test it out
> I will test it.
>> One of the problems we will run into, esp for Linux (I don't know about
>> other platforms) is that the user has a appended "pkgfmt" already on the
>> update URL, so in my experimenting, the update call failed because an
>> acceptable package was not found.
>  From my point of view this should not be a problem as it seems that the
> HTTP server neglects the URL query part in such a "static" case.
> I am not an expert here, please correct me if I am wrong.

well, I'll try it again...I have several versions to play with...I seem 
to recall I had to manually delete the pkgfmt business and then I got it 
to work.

I'll get back to you on this later today.

I think I will make a discussion thread to totally ditch the pkgfmt 
business from Linux update URLs. It would considerably simplify our lives.

>> Your analysis about just leading linux folks to the url of a page for an
>> update is great, but what to do about the existing information?
> Sorry, but I do not know what you mean by "what to do about the existing
> information?"
>> Anyway, copy your doc over to the web server, setup the redirect, and let
>> us know how things go.
> Yes, I will.
> Best regards, Oliver.


"Well, life has a funny way of sneaking up on you
  And life has a funny way of helping you out
  Helping you out."
                             -- "Ironic", Alanis Morissette

View raw message