openoffice-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rory O'Farrell <>
Subject Re: [PROPOSAL] Distribute only one source package
Date Sun, 08 Nov 2015 18:09:52 GMT
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.  However I fear that Windows builders may think only in terms of 7zip (or
zip as being  compression of choice).  For them we ought make available a package that opens
in the default Windows Archive Manager, whatever that is.

> I do not support this proposal as a first-choice alternative to what may be a surmountable
> 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
>    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 <>.
> 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
> 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 []
> > Sent: Saturday, November 7, 2015 15:08
> > To:
> > Subject: [PROPOSAL] Distribute only one source package
> > 
> > We currently distribute 3 source packages at
> >
> > 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:
> > For additional commands, e-mail:
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

Rory O'Farrell <>

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message