There is interesting discussion on this thread that devolves into what compression to use as the single source-package case.
I do not support this proposal as a first-choice alternative to what may be a surmountable problem. I want to speak to some higher-level issues, below. 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. One produced on Windows for Windows should not present the interoperability and interchange problems that other arrangements introduce. Unzip onto non-Windows platforms should also work properly. These things are relatively easy to check and confirm for a power user such as myself, despite my not being a core developer of the code itself. I will also document the procedure so that anyone can replicate it. It should be easy for other committers to unpack the zip and confirm its reliability and accuracy on Windows and other platforms. They could even add their counter-signing digital signatures. If that fails, then it would be time for a Plan B. (A possible unexpected difficulty may have to do with line ends on text files across platforms, depending on whether tools address that as well as SVN clients do.) - Dennis - - - - - - - - - - - - The TL;DR: I am going to appeal to the Apache Project Maturity Model because I believe it is applicable here, whatever the status of the document at <http://community.apache.org/apache-way/apache-project-maturity-model.html>. 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. Something that is not in this list, but I see as a corollary, is that how we do these things is part of demonstrating care for the downstream users of the software we produce, for whatever reason they want to consult, examine, learn from, or even develop with, and whenever they choose to do so with a given source release. - - - - - - - - - - - MY QUESTION: There should never be a permissions issue in unpacking a Zip file on Windows. The only barriers are (1) file names must be ones that are acceptable and unique when extracted into an NTFS file system and (2) empty directories are not created, even if loaded into later in the stream, and there is no use of Zip extensions that apply only to Unix systems and Unix permissions. There are also concerns about length of full-path file names. (Note that some of these apply to using SVN on Windows too.) My question is, on what platform were the troublesome Zips produced, using what tools? We may be seeing an interchange/interoperability problem that comes from inter-platform incompatibilities. MY CONCERN: These provisions are not just for project developers, but for the public. I don't think only distributing a .tar.bz2 is very adequate with respect to CD20. RE10 is presumably satisfied if there are no uses of patented technologies, and assuming that no deviations from basic .tar formatting are employed (e.g., no launching of shell scripts involved). 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 and also the packaging of .oxt extensions. It is also the packaging format of choice for OOXML, EPUB, and other domain-specific usages, including distribution of some libraries used in AOO and other projects. (I also notice that sometimes those Zips of libraries don't unpack properly on Windows, but rezipping them on Windows then works everywhere.) The convention has been to use Zip for Windows oriented access to the source and some flavor of .tar.* for the Unix-oriented world. The basic use of Zip for Windows tends to unzip easily on any platform that can deal with the filename and folder hierarchies. Although WinZip *will* unpack a .tar.gz (or .tgz) package, I do not know whether it will unpack a .tar.bz2. Expecting a member of the public who operates on Windows to know how to unpack a .tar.* is an unnecessary source of friction. I notice that 7z does handle .rar and .msi and perhaps tar.* compressions but I haven't checked those. - - - - - - - - - - - - - > -----Original Message----- > From: Andrea Pescetti [mailto:pesce...@apache.org] > Sent: Saturday, November 7, 2015 15:08 > To: dev@openoffice.apache.org > Subject: [PROPOSAL] Distribute only one source package > > We currently distribute 3 source packages at > https://archive.apache.org/dist/openoffice/4.1.2/source/ > 1) A .tar.bz2 file (209 MBytes) > 2) A .tar.gz file (276 Mbytes) > 3) A ZIP file (323 MBytes) > > The packages are equivalent, so any one would suffice. > > As discussed by Regina and Juergen recently, we ship #3 as a convenience > for Windows users but this leads to broken file permissions, so the > recommendation for Windows users is to use #1 or #2, which makes #3 > useless. > > I suggest, subject to lazy consensus, that we only distribute #1, i.e., > the .tar.bz2 file. > > Reasons: > * If we distribute one source package, it will be clear that we are all > testing and approving the same one > * .tar.bz2 offer better compression than .tar.gz > * bzip2 is ubiquitous today, so I don't believe that there are systems > capable of building OpenOffice which don't have bzip2 available > * better compression formats exist, but they are not as widely supported > as the three we are using now, so I'd stick with bzip2 > > This of course doesn't apply to 4.1.2, which is already released and > will remain available in all three formats. > > Regards, > Andrea. > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org > For additional commands, e-mail: dev-h...@openoffice.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
