Rob Browning writes:
> Kevin Ryde writes:
>
>> Hmm. I suppose if an add-on is removed by a flavour upgrade and that
>> remove fails for some reason then bits are left behind in what's now an
>> old directory.
>
> I think there were probably all kinds of reasons -- but I'm fairly
> certain that
Kevin Ryde writes:
> Hmm. I suppose if an add-on is removed by a flavour upgrade and that
> remove fails for some reason then bits are left behind in what's now an
> old directory.
I think there were probably all kinds of reasons -- but I'm fairly
certain that we did end up with a lot of dangli
Rob Browning writes:
>
> # The version-specific site-lisp dir, say emacs/21.1/site-lisp, needs
> # to be in share/FLAVOR so that as we upgrade from 21.1 to 21.2,
> # etc., add-on package bits don't get left behind.
Hmm. I suppose if an add-on is removed by a flavour upgra
Kevin Ryde writes:
> Rob Browning writes:
>>
>> investigate our load-path handling more carefully, perhaps even more so,
>> given that Emacs has changed its behavior over the past couple of major
>> releases -- but I also think that it's probably not something that we
>> should attempt right now
Rob Browning writes:
>
> investigate our load-path handling more carefully, perhaps even more so,
> given that Emacs has changed its behavior over the past couple of major
> releases -- but I also think that it's probably not something that we
> should attempt right now, this close to a release.
intrigeri writes:
> Rob Browning wrote (02 Dec 2012 20:34:59 GMT) :
>> For now, I'm inclined to fix the /usr/local issue, and then hope to
>> continue this discussion after the release.
>
>> Plausible?
>
> I think this totally makes sense.
> Thanks for tackling this RC bug :)
You're certainly we
Rob Browning wrote (02 Dec 2012 20:34:59 GMT) :
> For now, I'm inclined to fix the /usr/local issue, and then hope to
> continue this discussion after the release.
> Plausible?
I think this totally makes sense.
Thanks for tackling this RC bug :)
--
To UNSUBSCRIBE, email to debian-bugs-dist-req
Kevin Ryde writes:
> Rob Browning writes:
>> I suppose one argument for keeping the symlink is the possibility that
>> Emacs or add-on packages may look for that particular directory by name
>> (which sounds plausible to me).
>
> Sounds likely ... change the policy to match the practice :-).
>
8 matches
Mail list logo
