Hi folks, this ebuild installs in fact Version 3.5.0rc1 (according to the Help->About info) Is there any reason this ebuild has that version number and not 3.5.0_rc1? I am a little bit puzzled about the ebuild version numbers for libreoffice... 8) TIA
because rcs are done this way, if there wont be any more fixes the 3.5.0.1 will be declared final. That is why you mostly get just 3.4.5.2 (which is 3.4.5rc2 declared as final).
For what it's worth: I fully agree with Marc on that. The current numbering scheme is plain wrong, it puts the build-number top-front instead of the actual real release name - and this is confusing to users. There was a good reason why I did it the other way around in earlier releases, sometimes it might be useful to not just throw away all the experience that was accumulated over the years ;)
Tomáš, I think your point is that this avoids the unnecessary rebuild of the last rc, right? And I think this point is important because it really takes along time for this beast being built, so thanks. But OTOH its really a bit confusing. Do we have some mechanism in portage to rename a version without rebuild? This would be a good usecase for such a feature.
There is no mechanism for the rebuilds yet in portage. It is being discussed upstream to use actual rc in the name and force the rebuild because current release propagates itself as RC3. Anyway it is not a problem as usually all the rcs are hardmasked, it was not the case for 3.5.0 as I wanted it to get more testing. Probably won't do it next time. If people can live that this package will have weird name like 3.5.1.4 or 3.7.2.3 instead of 3.5.1 or 3.7.2 i think this can even be closed.
I could easily be ignorant on this topic, but it seems that the official Gentoo Development Guide discusses this issue... http://devmanual.gentoo.org/ebuild-writing/file-format/index.html Specifically, there is the "_rc" suffix, which can be appended to the version number. And for multiple release candidates in a series, "any of these suffixes may be followed by a non-zero positive integer." Which is how upstream does it, it appears. For example: http://download.documentfoundation.org/libreoffice/testing/3.5.0-rc3/rpm/x86/LibO_3.5.0rc3_Linux_x86_install-rpm_en-US.tar.gz So, now I am thinking about "3.5.0 Final" and the use of "3.5.0" by upstream. For example: http://download.documentfoundation.org/libreoffice/stable/3.5.0/rpm/x86/LibO_3.5.0_Linux_x86_install-rpm_en-US.tar.gz And so, is libreoffice-3.5.0.3.ebuild equivalent to "3.5.0 Final"? Or, will "3.5.0 Final" be named libreoffice-3.5.0.4.ebuild? Either way, how would a user know which one is "3.5.0 Final"? And, what if upstream were to release a 3.5.0.1? Wouldn't that mess up the current Gentoo LibreOffice version number scheme? (or, perhaps upstream wouldn't add a 4th digit like that?) (Please ignore this comment if it is completely unhelpful. None of the above is to diminish my appreciation for the work Tomáš Chvátal has put into the package itself)
I am using upstream numbering, the 3.5.0.3 is upstream version of sources, they get renumbered wrt release of rpms to 3.5.0rc3 which indeed are final release for 3.5.0. For more look here: http://download.documentfoundation.org/libreoffice/src/3.5.0/ So we don't have to worry that we clash with upstream, I just didn't want to use different name for ebuild and for the final, because if i would rename 3.5.0.3 to 3.5.0_rc3 and upstream then decide it is final i would have to copy the ebuild to 3.5.0 and you would all needlessly rebuild the package.
Cool, thanks. Makes sense. I'm still wondering, though, how would a regular user know which ebuild is "3.5.0 Final" when only RC versions are listed. I see the benefit of avoiding a needless rebuild. But that benefit, it seems, is limited to just those running "testing" and does not apply for the rest of the Gentoo world running "stable". BTW, today I read http://blogs.gentoo.org/scarabeus/2012/02/14/the-new-disk/. Thanks for the update and for staying in the game. :-)
In the end this is at maintainer's discretion.
