Re: A proposal for removing obsolete packages

[Andrew Hyatt <ahyatt@gmail.com>]

Richard Stallman <rms@gnu.org> writes:

> [[[ To any NSA and FBI agents reading my email: please consider    ]]]
> [[[ whether defending the US Constitution against all enemies,     ]]]
> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
>
>   > >   > For example, a package that is declared obsolete during the development
>   > >   > of Emacs 25 would be moved to obsolete, and a message would be added to
>   > >   > say that "<package> is obsolete and will be removed in Emacs 27". It
>   > >   > couldn't be removed in Emacs 26 because it didn't start Emacs 25 in
>   > >   > obsolete.
>   > >
>   > > I agree.  But we should not be rigit about deleting it in Emacs 27,
>   > > either.  Depending on how the feature is used, we might want to save
>   > > it longer.  Features used in Lisp code may need to remain longer.
>
>   > Could we instead not move things into obsolete if we didn't think they
>   > were removable?
>
> Moving them to 'obsolete' would be done at the first step, according to
> that proposal.  The question I am raising is when to delete them entirely.
>
>   > Also, can you give an example of something that is obsolete but
>   > shouldn't be removed?  That might help me understand your concern.
>
> defadvice might be a good example.

OK, that sounds like a completely valid concern.  I agree that some
packages that are well used may need to stick around for longer, and
that it should be at the discretion of the maintainer.  I'd hope that
this would be very unusual, though.

One way to make it unusual (and allow things like advice to be placed in
obsolete and removed later) would be if elisp functionality such as
defadvice had their APIs maintained but implemented on top of newer
functionality. For example, a macro in nadvice.el could re-implement
defadvice on top of the replacement functions. That would allow us to
remove the old implementation safely. I haven't thought about this
example very deeply, though, perhaps it is not so easy.