Rory O'Farrell wrote:
On Sun, 8 Nov 2015 09:51:07 -0800 "Dennis E. Hamilton" wrote:
There is interesting discussion on this thread that devolves into what
compression to use as the single source-package case.
My reaction is that most (all?) linux/non-windows builders will be happy with
the proposed .bz2 compression.
Last time I had the occasion to see them, all normal file decompressors
for Windows (Winzip, WinRAR, 7-Zip) were able to extract a .tar.bz2 archive.
So, speculations aside, is there anyone who has a working stack for
building OpenOffice on Windows and feels it would be problematic to
extract a .tar.bz2 archive?
For them we ought make available a package that opens in the default Windows
Archive Manager, whatever that is.
Do Windows developers really use Windows' built-in utilities for
unzipping? I really think that the minimal stack for building OpenOffice
on Windows includes some .tar.bz2-capable programs. We do download and
expand .tar.bz2 files as part of the build process, so it seems obvious
that this is not an issue for Windows developers, meaning that this is
covered by standard tooling.
MY OFFER: I will happily produce a signed, Windows-acceptable Zip for a source
release, using an SVN working copy of the released branch and version.
So long as we (as the project) vote on ONE single source package (the
.tar.bz2 one), I'm absolutely OK with you doing that. People who want to
distribute their own "unofficial" archive produced with their utility of
choice can do that. We can advertise it as a "convenience source
package" on http://openoffice.apache.org/downloads.html and store it on
people.apache.org. This is entirely possible.
What we must avoid is that, in theory (since it practice it would be
interesting to know how many people do that), we ask people who vote on
a release to download 3 source packages, expand all of them (wasting
several GBytes of disk space) and ensure they are equivalent. If we have
one "canonical" source package, everybody knows what we are voting on.
Then we can have any number of "unofficial" archives in other formats.
One produced on Windows for Windows should not present the interoperability
and interchange problems that other arrangements introduce.
No idea on this. Maybe yes, maybe not.
I am going to appeal to the Apache Project Maturity Model because I believe it
is applicable here ...
I think the relevant considerations of what should be *strived*for* are
CD10: The project produces Open Source software, for distribution to the public
at no charge.
CD20: The project's code is easily discoverable and publicly accessible.
CD30: The code can be built in a reproducible way using widely available
standard tools.
RE10: Releases consist of source code, distributed using standard and open
archive formats that are expected to stay readable in the long term.
bzip2 satisfies all of these requirements. We can ask dev@community if
you have any doubts. For sure, many Apache projects do not provide a ZIP
file (I admit they tend to prefer .tar.gz to .tar.bz2); no Apache
project that I know of distributes 3 source packages.
My question is, on what platform were the troublesome Zips produced, using
what tools?
They were done on a Mac, but this (like most of this discussion) is
entirely irrelevant. The fact that the .ZIP version has (probably)
issues is yet another reason to kill it, but my main reason is to make
it clear what we are voting on.
I note also that Zip format is considered standard and open enough that it is
the format employed for the ODF packages used by OpenOffice
Here other considerations apply, like decompression speed. But again,
I'm not proposing to drop ZIP since it's not standard. I'm proposing to
drop it since it's redundant.
Although WinZip *will* unpack a .tar.gz (or .tgz) package, I do not know
whether it will unpack a .tar.bz2.
Several years ago it did. I assume it still does.
I notice that 7z does handle .rar and .msi and perhaps tar.* compressions but I
haven't checked those.
If you want to try in practice, try with this:
http://serf.googlecode.com/files/serf-1.2.1.tar.bz2
but I'm confident that you will be able to expand it on any machine
where OpenOffice can be built.
By the way, that library is a standard requirement we incorporate in
OpenOffice, so any system able to build OpenOffice must expand it at
some point. This is the reason for me to assume that keeping only
.tar.bz2 is not an issue. But, provided we get consensus on wanting ONE
"official" source package, if someone has real arguments for preferring
.tar.gz over .tar.bz2, .tar.gz may work too.
Regards,
Andrea.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org
