Jurgen,

>From my perspective as a user, I would love to have an official YUM
repository with AOO available.  This would break a lot of barries from
less technical people on RPM distributions. I would suppose the same
could be said about APT repositories.

Now we have an issue... A vendor (Fedora/Red Hat) a few years ago
introduced an "Epoch" in their packages. As I said before, once
defined, Epoch will be used as the supreme comparison method. Epoch
and names together provide a huge barrier to have products from the OS
vendor and Apache to be installed simultaneously, which has some
potential fixes:

 1) Rename the RPMs - There might be some advantages on this at all
levels, either technical and towards user friendliness;

 2) Introduce Epoch:
     1 - Use Epoch one: would allows us to dodge a few issues with
Fedora and Red Hat, but with openSUSE would probably create a
situation where Apache RPMs would take all priority over OS vendor
packages. If we don't like it the way Red Hat does, doing the same
ourselves with openSUSE doesn't sound nice, but, it's a way out;
     2 - Use an absurd Epoch value (like 2000, Sun does it with JDK);
this would mean that if a YUM repository with our RPMs is available,
automatically it will replace Libre Office... Which makes some sense
since if a user adds your repo, it probably means that he/she wants to
use your product.


Now this isn't really a fun choice to do.... but the current way,
asking users to blacklist packages and give them a few bits of low
level work to do before being able to use the software... that
probably harms more Apache OpenOffice than choosing between the
approaches above.

I don't mind writting up a document with this contents, demonstration
and eventually point a few other things that can be improved in the
RPM metadata fields.

I can't speak for non-RPM platforms as I don't use them. Please take
into consideration that the changes I mentioned above (either names or
Epoch) are done during packaging and only require that the spec
templates are adjusted. I don't mind exploring this much deeper and
provide a document if someone can point me the right namespace on the
wiki to do it.

NM



2012/5/21 Juergen Schmidt <jogischm...@googlemail.com>:
> Am Samstag, 19. Mai 2012 um 19:32 schrieb Dennis E. Hamilton:
>> One enduring solution would be to break with the past and not use the same 
>> file names for the binary bits, the same registry keys, etc., any longer. 
>> That would solve a few problems on Windows too.
>>
>>
>
>
> I think we own the name and we are probably not the project who should change 
> any names.
> We should be careful with this kind of changes because we can potentially 
> break a lot of existing projects who rely on names, registry entries etc.
>
> So please be careful with such changes without deeper analysis what depends 
> in this...
>
> Juergen
>>
>> - Dennis
>>
>> -----Original Message-----
>> From: Kay Schenk [mailto:kay.sch...@gmail.com]
>> Sent: Saturday, May 19, 2012 10:01
>> To: ooo-dev
>> Subject: Linux install issues
>>
>> Hi all--
>>
>> It seems we are running into a number of very difficult problems with Linux
>> installs, the latest just e-mailed to this list this morning, due to the
>> way some vendors have installed LO.
>>
>> see:
>>
>> http://markmail.org/message/qz72ouzjvcm7uyfn
>>
>>
>> I'd really like to provide additional help in the install guide:
>>
>> http://www.openoffice.org/download/common/instructions.html
>>
>> but I'm at a loss as to what this should say.
>>
>> I took a look at SOME of the postings on the support forums and well, still
>> at a loss. Generally, it seems that completely uninstall the old OOo 3.3 is
>> a given (please correct me if I'm wrong about this), but how to handle some
>> of the LO overlap?
>>
>> Can we get some opinions on what's the most accurate way to go about
>> installing AOO 3.4 on linux?
>>
>> * completely de-install LO first? install AOO 3.4, the re-install LO?
>> * completely de-install old OOo 3.3? and then?
>>
>> Thankfully, I did not run into these kinds of issues with my distro.
>>
>> --
>> ----------------------------------------------------------------------------------------
>> MzK
>>
>> "The reports of my death are greatly exaggerated."
>> -- Mark Twain
>>
>>
>
>



-- 
Nelson Marques
// I've stopped trying to understand sandwiches with a third piece of
bread in the middle...

Reply via email to