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