Re: A tip, a question, and feature request ...

On Wed, Apr 17, 2013 at 02:07:04PM -0400, Magnus Thor Torfason wrote:
> On 4/10/2013 7:54 AM, Adam Spiers wrote:
> > On Tue, Apr 09, 2013 at 03:45:17PM -0400, Magnus Thor Torfason wrote:

[snipped]

> >>     In this case, one might
> >>     even imagine that the existence of a corresponding file in the
> >>     stow/package directory would be perceived to be a conflict (I
> >>     would expect the actual use case for this switch to always or
> >>     almost always be executed with an empty or (even better) absent
> >>     stow/package directory).
> >
> > Probably better to let the caller decide whether they want to call it
> > with an empty or absent package directory.
> 
> Agreed, I'm thinking that when there would be overwriting it would
> be appropriate to give a warning/error. One might for example
> accidentally try to adopt into the wrong version of a recently
> upgraded package.
> 
> Possibly require --force to actually overwrite contents of package
> directory?

Sounds good.

> >>   - Update stow and chkstow so that they correctly handle alien
> symlinks.
> >
> > Agreed.
> >
> >>     This would apply to the following commands at least:
> >>       > stow --adopt <package>
> >
> > stow --adopt should currently ignore alien symlinks.  If it doesn't,
> > that's a bug.  I'm not sure what changes you are proposing to this
> > behaviour?
> 
> It behaves as you describe. My thought was that if a package
> installs symlinks (like mcview -> mc), they won't be correctly
> uninstalled on
> "stow --adopt-all <package-name> && stow -D <package-name>"
> And if there exist identically named files in the package dir, that
> is a conflict I believe (with the current --adopt switch). I admit
> I'm not sure what, if anything, would be a better behavior. (see
> next para).
> 
> >>       > stow --adopt-all <package>
> >
> > Right, although adopting alien symlinks which are relative rather than
> > absolute could be tricky, since the target of the original alien
> > symlink is relative to its location within the stow target directory,
> > and this target would need to be rewritten during adoption to be
> > relative to its location within the stow package directory.
> 
> Yes, it turns out that this would be pretty complex: Absolute links
> or relative links that stay within the same package do work well (I
> tested with the mcview links. But relative links that point neither
> into the package itself nor into the stow dir (so owned by stow)
> would be very problemetic.

Yeah, you're probably right.  I think it's important to distinguish
between symlinks which point to files or directories within the same
package, and those which point elsewhere.  This distinction
corresponds to Stow's notion of ownership - I would most likely not
consider the former as "aliens".

> Currently my inclination would be to have --adopt-all choke on such
> links unless a --force parameter were passed. But it is far from
> obvious what is the best thing to do in that edge case.

Yeah ... I can't actually think of a use case for a Stow package which
would need to symlink to something it didn't own, but there probably
is a valid use case regardless.

> >>       > chkstow -a
> >>     It seems to me that chkstow -a would have to be aware of the
> >>     location of the stow directory to be able to do this,
> >>     probably by adding a --dir param to chkstow.
> >
> > Agreed, although in the absence of a --dir parameter, the presence of
> > a `.stow' file in the stow directory might be sufficient.
> 
> OK, so this would work by traversing all the parents of a symlink's
> targets to see if any of them had a .stow file in it?

Correct.

> That seems
> like a bit of overhead. Any ideas for more efficient solutions for
> that?

I highly doubt this would add any significant overhead.

> And on a related note. Is there a specific reason for separating
> stow and chkstow?

If there is, it's lost in the mists of time ...

[snipped]

> > Great suggestions; many thanks   Sadly it is very
> > unlikely that I will have time to implement any of these any time
> > soon; however I would be delighted to review and accept pull requests
> > as long as they adhere to these guidelines ...
> >
> > http://blog.adamspiers.org/2012/11/10/7-principles-for-contributing-patches-to-software-projects/
> 
> Cool. We'll see if anything happens on my front. I've got everything
> up and running now with my aliases and functions, but I'll see
> whether it starts itching again. I've cloned:
> https://github.com/aspiers/stow.git
> and am running a compiled (and stow-managed) installation of stow,
> so it's straightforward to edit. Would any updates be best submitted
> as pull requests to that repo?

Yes please :-)