* Import a debian/ tree from an older package and update it. * Import a .spec file from somewhere and update it. * Distinguish between .stow and (undocumented) .nonstow ** .stow is for marking stow directories - avoids altering them but also allows --override to work ** .nonstow should be only for protecting non-stow directories against modification by stow but currently allows modification via --override. ** Documentation needs to be clear on this. * Prevent folding of directories which contain ignored files * Honour .no-stow-folding and --no-folding * Add semi-automatic conflict resolution *** STOW_RESOLVE_CONFLICTS="non_stow_symlinks=t stow_symlinks=r" *** Add documentation about conflict resolution * 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 files '.nonstow' and '.notstowed'. Can they be removed? * 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: