78 lines
3.2 KiB
Plaintext
78 lines
3.2 KiB
Plaintext
* Honour .no-stow-folding and --no-folding
|
|
* Support ignore lists in files
|
|
*** Implement.
|
|
*** Add documentation about ignore lists.
|
|
***** Justification for having stow ignore lists independently of VCS ignore lists
|
|
******* If a file is in the VCS ignore list for its containing repo
|
|
********* generated during development
|
|
probably shouldn't be stowed
|
|
********* generated during compilation / install
|
|
*********** could be an intermediary file
|
|
again, probably shouldn't be stowed
|
|
*********** but most likely a file to install
|
|
e.g. compiled binary/library/docs - should be stowed
|
|
******* If a file is not in the VCS ignore list for its containing repo
|
|
********* it's probably tracked by the VCS - part of the repo
|
|
********* could intended for end use
|
|
*********** e.g. script/config file requiring no modifications, docs
|
|
should be stowed
|
|
********* or intended only to be used during compilation / build phase
|
|
shouldn't be stowed
|
|
*** (Eventually) rsync-like include/exclude lists instead of ignore lists
|
|
* Add semi-automatic conflict resolution
|
|
*** STOW_RESOLVE_CONFLICTS="non_stow_symlinks=t stow_symlinks=r"
|
|
*** Add documentation about conflict resolution
|
|
* Make CPAN-friendly via Module::Build
|
|
*** Include test-time dependencies on Test::More and Test::Output
|
|
* get account on fencepost.gnu.org (email accounts@gnu.org)
|
|
set up copyright papers?
|
|
'assign.future' and 'request-assign.future.manual'
|
|
|
|
* Figure out what needs the option 'nostow' 'notstowed'. Can they be removed?
|
|
|
|
* _texi2man_ needs author/copyright/license to be completed
|
|
|
|
* Update http://directory.fsf.org/project/stow/
|
|
|
|
* Update savannah 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 the ownership of links that it _operates_ on,
|
|
not on all the elements of the path.
|
|
|
|
* emacs local variables
|
|
Local Variables:
|
|
mode: org
|
|
End:
|