00dani/stow
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity

Initial Import

Browse source
This commit is contained in:
Troy Will 2009-04-12 20:38:34 -07:00
commit 38dcdcb08c
42 changed files with 24923 additions and 0 deletions
Download patch file Download diff file Expand all files Collapse all files

49
TODO Normal file
View file

@ -0,0 +1,49 @@
* get account on fencepost.gnu.org (email accounts@gnu.org)
set up copyright papers?
'assign.future' and 'request-assign.future.manual'
* Update stow.texi
- The email address in 'Reporting Bugs' needs to be updated
* Figure out what needs the optin 'nostow' 'notstowed'. Can they be removed?
* _texi2man_ needs author/copyright/license to be completed
* Update http://directory.fsf.org/project/stow/
* Update savanaugh CVS
* Check that all email addresses are working: need an account on fenchpost for
this bug-stow@gnu.org, help-stow@gnu.org
* Get some pre-testers: need to find appropriate mailing list?
* Announce release on info-gnu@gnu.org.
* Autodetect "foreign" stow directories
From e-mail with meyering@na-net.ornl.gov:
> My /usr/local/info equivalent is a symlink to /share/info
> because I want installs on all systems to put info files in that
> directory. With that set-up, stow chokes on fact that
> /usr/local/info is a symlink.
[...] Stow is designed to be paranoid about modifying anything it
doesn't "own." If it finds a symlink in the target tree (e.g.,
/usr/local/info) which doesn't point into the stow tree, its
paranoid response is to leave it the hell alone. But I can see in
this case how traversing the link and populating the directory on
the far end would be OK. Question: is that a special
circumstance, or would it always be OK to populate the far end of
a symlink in the target tree (when the symlink points to a
directory in a context where a directory is needed)? And: if it's
a special circumstance requiring a command-line option, should the
option be a mere boolean (such as, "--traverse-target-links") or
should it be an enumeration of which links are OK to traverse
(such as, "--traversable='info man doc'")?
Does Version 2 fix this? (Kal)
I think that because it never needs to create /usr/local/info,
it only needs to check th ownership of links that it _operatates_ on,
not on all the elements of the path.