> Actually, the feedback I got at FOSDEM was to focus on packaging trunk for > the time being. > > But indeed, the biggest effort is on packaging in a way that it is > satisfactory for everybody, and for this first step it doesn't really make > a technical difference whether we use 3.4.1, a recent 4.0 milestone or 4.0, > since the major infrastructural changes were already done in OpenOffice > 3.4.0 and newer versions do not introduce new dependencies (although trunk > uses an updated product name, that could help in solving some conflicts). > > In Fedora, even installing OpenOffice manually (i.e., by downloading RPMs > from the OpenOffice website) is problematic since: > 1) it won't install cleanly due to the conflicting "soffice" alias > 2) even if you force installation, "yum update" can wipe out OpenOffice > since one of the LibreOffice RPMs obsoletes the OpenOffice RPMs. > > It is surely possible to do better, and to do so in a way that leaves the > user experience for LibreOffice end-users unchanged. This is what I see as > a first step. > > Note that I haven't had time to check with F18 yet, so I welcome feedback > on this if someone can test before I do. > > Let's take a look at a similar (although of course not identical) situation with respect to a package that is very similar to another - indeed will conflict on certain files even - and the process/time that took to get packaged...
https://bugzilla.redhat.com/show_bug.cgi?id=875150 This the the MariaDB packaging review request. The RPMs already existed upstream so it theoretically should have been a pretty simple cleanup in line with Fedora Pacakaging Guidelines. It took from 9/11/12 to 10/1/13 to get that from the initial big to approved... The only existing codebase form which to discuss this and test a *working* office suite packaged by RPM is 3.4.1 ... Right now there's no roadmap for 4.0 - no milestone dates, alpha dates or beta dates... The best that exists for this is a nightly snapshot from trunk covered in caveats about how unstable it's likely to be. The openoffice.org wiki doesn't even mention 3.4 much less future plans for 4.0 on it's features page! http://wiki.openoffice.org/wiki/Features Could you have a chat with Rob Weir to clarify IBM's timeline for the 4.0 package and provide some hard milestone dates rather than the current vague "April 2013" ? Annoyingly the AOO thread has split in my email client by I agree the discussion about the IBM Symphony dump ( licensing concerns as out of scope given that won't be packaged and all code will be review for license whilst being merged to AOO however this inject of proprietary code as opposed to the open tested code of 3.4.1 on a tight timeline is I would submit a concern as to the likelihood of bugs and slippage from the current vague date. Out of curiosity I just downloaded the tarball (of x86_64 RPMs) on the oo.org website to see how they would behave whilst installing to my F18 system... Yum reported no conflicts on install - which surprised me (although I didn't install the desktop integration stuff) - and then I noticed it installed to /opt which is an immediate violation of the packaging guidelines so there's not actually a reasonably clean (like the mariaDB ones were) to start from in the first place... There's substantial risk here to the reputation of Fedora trying to squeeze this untested application into a F19 timeline when it's rushed into the distribution rather than taking a step back and working through the conflict issues (and others involved) and certainly with the 3.4.1 code no gain to Fedora users at all over the existing LibreOffice suite. Realistically this packaging discussion should have been started back last year on the 3.4.1 release or shortly thereafter - perhaps with an apache supported but unofficial yum repository until such time as the RPMs fell inline with Fedora guidelines and then the discussion could have been had well ahead of the feature deadline for a release and definitely more than 3 weeks from branch...
-- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
