Item602: Release tarball could be in a subdirectory
Priority: Urgent
Current State: Closed
Released In: 1.0.0
Target Release: patch
Applies To: Engine
Component:
Branches:
The release tarball is homed in the top directory of the foswiki installation (i.e. extracting the tarball places files in the current directory and creates the data/, lib/, bin/ etc directories underneath).
To prevent accidental local directory pollution could the install be homed in a subdirectory.. e.g. an extract would create a directory called Foswiki-1.0.0-b2/ or something similar and all the subdirectories and files would be contained in this single initial subdirectory?
i.e. instead of the tarball being:
AUTHORS
bin/
bin/manage
bin/configure
bin/setlib.cfg
it would be:
Foswiki-1.0.0-b2/AUTHORS
Foswiki-1.0.0-b2/bin/
Foswiki-1.0.0-b2/bin/manage
Foswiki-1.0.0-b2/bin/configure
Foswiki-1.0.0-b2/bin/setlib.cfg
Also, another comment.. on the release page (
Download) could there be a link for people to report their experiences, maybe even as a comment page, to assist the developers in gathering feedback (right now there's no obvious link from the download page on how a person can contribute feedback).
I agree - I'd rather make the tarball less dangerous to open.
--
SvenDowideit - 30 Dec 2008
also agree. this is a common complaint about TWiki tarballs since the O'Wiki fork days (and before, i imagine)
Yes let us fix this now. This is the right moment - before the real 1.0.0 release.
Noone with a bit of common sense ever unpacks a tgz on top of an existing directory and it is not the way I recommend in the upgrade documentation either.
If this gets done for 1.0.0 then remember that I need to also update the installation topic as well as the upgrade topic. Just a small change.
But yes. This is a pain in the butt so let is fix it now.
I am not sure I can take this task, Sven can you?
Agreed, let's not repeat old mistakes. Taking off WFF so it;s in the Release Blockers list
--
CrawfordCurrie - 04 Jan 2009
As I'm not using Subversion as a backend, I can't use tools/build.pl to try it out, but I've done a trunk checkout to test, and thus I've fixed it. I hope I didn't break anything in the process...
Basically, I'm adding a check in
BuildContrib so that you can override the tmpDir, and I'm simply over-ridding it in build.pl, for both
stage
and
archive
targets.
--
OlivierRaginel - 04 Jan 2009
for testing this, it's also important to make sure that normal plugins still build and upload properly. i believe that has been tested this morning when arthur updated a bunch of plugins
--
WillNorris - 05 Jan 2009
Tested with both build of Foswiki and build and upload of extension
Thanks for this fix
I will need to commit a doc update before I close this.
--
KennethLavrsen - 06 Jan 2009
worked for me, just updated to Foswiki-NS plugins
--
EugenMayer - 07 Jan 2009
Someone has edited this page using the WYSIWYG editor.The WYSIWYG editor goes and blasts away effort I might have gone to in presenting or formatting a list of information using HTML tags (especially div). The newlines in a <pre> section are not preserved.
Please, everyone, the
WYSIWYG EDITOR MANGLES PAGES. Don't use it. If you want to know how then have a look at my home page which disables use of the WYSIWYG editor.
--
PeterPayne - 21 Jan 2009
i have disabled the "WYSIWYG" editor for this Tasks web.
--
WillNorris - 21 Jan 2009