TODO

   1 * Add support for pre/post-(un)install hooks
   2
   3   This would allow correct handling of the Info dir file via
   4   install-info, amongst other things:
   5
   6 *** http://unix.stackexchange.com/questions/73426/dealing-with-gnu-stow-conflicts
   7 *** http://article.gmane.org/gmane.comp.gnu.stow.general/6661
   8
   9 * Get permission for next documentation release to be under FDL 1.3
  10
  11 * Import a debian/ tree from an older package and update it.
  12
  13 * Import a .spec file from somewhere and update it.
  14
  15 * Distinguish between .stow and (undocumented) .nonstow / .notstowed
  16
  17 ** .stow is for marking stow directories - avoids altering them
  18
  19    but also allows --override to work
  20
  21 ** .nonstow should be only for protecting non-stow directories against modification by stow
  22
  23    but currently allows modification via --override
  24
  25 ** .notstowed is only honoured by chkstow
  26
  27 ** Documentation needs to be clear on this.
  28
  29 * Prevent folding of directories which contain ignored files
  30
  31 * Honour .no-stow-folding and --no-folding
  32
  33 * Add semi-automatic conflict resolution
  34
  35   (This idea is possibly obsoleted via --override and --adopt.)
  36
  37 *** STOW_RESOLVE_CONFLICTS="non_stow_symlinks=t stow_symlinks=r"
  38
  39 *** Add documentation about conflict resolution
  40
  41 * Autodetect "foreign" stow directories
  42
  43 From e-mail with meyering@na-net.ornl.gov:
  44
  45     > My /usr/local/info equivalent is a symlink to /share/info
  46     > because I want installs on all systems to put info files in that
  47     > directory.  With that set-up, stow chokes on fact that
  48     > /usr/local/info is a symlink.
  49
  50     [...] Stow is designed to be paranoid about modifying anything it
  51     doesn't "own."  If it finds a symlink in the target tree (e.g.,
  52     /usr/local/info) which doesn't point into the stow tree, its
  53     paranoid response is to leave it the hell alone.  But I can see in
  54     this case how traversing the link and populating the directory on
  55     the far end would be OK.  Question: is that a special
  56     circumstance, or would it always be OK to populate the far end of
  57     a symlink in the target tree (when the symlink points to a
  58     directory in a context where a directory is needed)?  And: if it's
  59     a special circumstance requiring a command-line option, should the
  60     option be a mere boolean (such as, "--traverse-target-links") or
  61     should it be an enumeration of which links are OK to traverse
  62     (such as, "--traversable='info man doc'")?
  63
  64 Does Version 2 fix this? (Kal)
  65 I think that because it never needs to create /usr/local/info,
  66 it only needs to check the ownership of links that it _operates_ on,
  67 not on all the elements of the path.
  68
  69 * emacs local variables
  70   Local Variables:
  71   mode: org
  72   End: