> -----Original Message----- > From: Kay Schenk [mailto:kay.sch...@gmail.com] > Sent: Friday, August 5, 2016 09:36 > To: OOo Apache <dev@openoffice.apache.org>; Dennis Hamilton > <dennis.hamil...@acm.org> > Subject: Re: [PACKAGING 4.1.2-patch1 Binaries] (was RE: [TESTING] > Applying openoffice-4.1.2-patch1 for Windows) > > On Fri, Aug 5, 2016 at 9:28 AM, Dennis E. Hamilton > <dennis.hamil...@acm.org> > wrote: > > > Branching off the part that is not about the Windows 4.1.2-patch1 > > [TESTING]. > > > > > -----Original Message----- > > > From: Marcus [mailto:marcus.m...@wtnet.de] > > > Sent: Thursday, August 4, 2016 15:52 > > > To: dev@openoffice.apache.org > > > Subject: Re: [TESTING] Applying openoffice-4.1.2-patch1 for Windows > > > > > > Am 08/05/2016 12:26 AM, schrieb Kay Schenk: > > [ ... ] > > > > > > > > hmmm...well no zips for Mac, Linux32, or Linux 64 -- yet. > > > > > > > > Should we get started on these? > > > > > > it depends what we want that they should contain. The ZIP file for > > > Windows contains a LICENSE and NOTICE file as well as an ASC file > for > > > the DLL. As it is only a patch IMHO we don't need to provide another > > > LICENSE and NOTICE file which is already available in the OpenOffice > > > installation. Also the ASC is not necessary as we provide it already > > > (together with MD5 and SHA256) for the whole ZIP file. > > [orcmid] > > > > I think there is a misunderstanding. Two matters: > > > > 1. The use of LICENSE is required by the ALv2 itself, and the ASF > > practice is to include NOTICE as well on binary distributions. The > patch > > qualifies, especially when it is moved to general distribution. It is > also > > easy and harmless to provide. > > > > 2. The reason for preserving the .asc on the shared-library binary is > > because it authenticates with respect to who produced it and > establishes > > that it has not been modified as supplied in the package (or as the > result > > of some glitch in creation of the Zip). It provides a level of > > accountability and, also, auditability. > > > > Even though few people will check all of these, they remain possible > to be > > checked. Since this is a matter of security vulnerabilities and > involves > > elevation of privilege to perform, I believe it is important to > demonstrate > > diligence and care, so that users have confidence in this procedure to > the > > extent they are comfortable. Also, if it becomes necessary to > troubleshoot > > a problem with these patch applications, we have the means to > authenticate > > what they are using to ensure there are no counterfeits being offered > to > > users. > > > > > > That means that only the README and library file remains. > > > > > > When the README for Windows keep its length then I don't want to > copy > > > this on the dowload webpage. ;-) > > > > > > So, when we put the README for all platforms in their ZIP files then > we > > > can just put a pointer to it on the download webpage and thats it. > > [orcmid] > > > > Yes, that seems like a fine idea. The README can be linked the same > way > > the .md5, .sha256, and .asc are linked. > > > > Also, the README may become simpler if we can link to some of the > > information and not have so much detail in the README text itself. It > > might even be useful to have an .html README for that matter. But > that is > > all extra. Right now I think we want to get into the testing and see > how > > to smooth what we have. > > > > PS: A friend of mine is looking into the MacOSX situation. He points > out > > that one can use the Finder to do the job without users having to use > > Terminal sessions. I don't have further information at this time. > > > > PPS: The inclusion of scripts that do the job is also worthy of > > consideration, perhaps making it unnecessary to build executables. I > will > > be looking at finding a .bat file that works safely for the Windows > case. > > That can make the instructions much shorter :). > > > > ??? I think you'd still need the executables as part of the payload. But > batch or script files would make the "installation" easier. We should > certainly consider this for future patches. [orcmid]
Yes, for the Windows case the .bat would be inside the Zip along with the other material. It would be extracted along with the other material. But then it can be executed where unzipped by an user running it as administrator in place. So all of the renaming and copying business would be semi-automatic and users operating from non-administrator accounts would only have to authorize administrative operation once (it is to be hoped). There is a variant that involves what is called a self-extracting Zip (an .exe file) that will run a command after doing so. I don't know whether we want to do that, but it would be a way to create an installer for the patch. That is a potential future step to explore for the Windows case. One step at a time ... > > For this situation, we may as well go with what we've got I think. > > Linux is very straightforward. I don't know anything about Macs. I do > know > that the Windows varients complicate things quite a bit. > > > > > > > > To cut a long story short: > > > I would say yes for a ZIP file for every platform. > > [ ... ] > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org > > For additional commands, e-mail: dev-h...@openoffice.apache.org > > > > > > > -- > ---------------------------------------------------------------------- > MzK > > "Time spent with cats is never wasted." > -- Sigmund Freud --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
