tldr: Dear team, are there any objections to making a team upload using the dummy package approach? It's what at least two users want, and it guards against harming relations with upstream Emacs. The existing state of things is between useless, embarrassing, and harmful, so let's fix this.
Sean Whitton <spwhit...@spwhitton.name> writes:
> Hello,
>
> On Sun 07 May 2023 at 04:42PM -04, Nicholas D Steeves wrote:
>
>> Is there a practical argument against adding versioned Provides to
>> either emacs-common or emacs-el (as appropriate)? Something like
>>
> I believe that changes of this nature are not appropriate at this stage
> of the freeze. I wish we had done something about this sooner, but
> elpa-org is undermaintained.
>
With a potential harm argument ("not appropriate"), shouldn't one also
consider the social cost of doing nothing? With users, as well as to
our rapport with upstream? See below.
> I don't think we should kick it out, because having a slightly older Org
> seems less bad than also kicking out the rdeps, on balance.
>
Another way of articulating the problem:
(without elpa-org installed) M-x org-version
Org mode version 9.5.5 (release_9.5.5 @ /usr/share/emacs/28.2/lisp/org/)
(with elpa-org installed) M-x org-version
Org mode version 9.5.2 (9.5.2 @ /usr/share/emacs/site-lisp/elpa/org-9.5.2/)
Elpa-org shadows the built-in copy. 9.5.3's bug fixes appear to
indicate that 9.5.2 may be unusable for users of Org's
bibliography-related functions, and of course there are a number of
other bug fixes between 9.5.2 and 9.5.5. Is it really conscionable to
/disable/ bug fixes that Emacs 25 provides in built-in Org-mode? Is it
really conscionable to do this to upstream? When we ask them to
accommodate us for native-comp-related things, shouldn't we also
demonstrate that we support their work in other areas of Emacs?
All users who have elpa-org installed in bullseye will be affected when
upgrading, as well as all elpa-org-contrib users. Release notes can
advise the former to remove elpa-org, but we shouldn't advise
elpa-org-contrib users to use 'equivs' to make emacs Provide a virtual
elpa-org.
Maxim Nikulin <m.a.niku...@gmail.com> writes:
> On 07/05/2023 20:34, David Bremner wrote:
>> Maxim Nikulin writes:
>
> I am against *removing* elpa-org from bookworm. I have a hope that it is
> possible to submit *empty* elpa-org package and it still can be accepted
> to bookworm. No dependencies will be broken, users will get a few more
> fixes from built-in Org shipped in emacs-el. If a newer Org appear later
> in next Debian releases (or in backports) users will get it.
>
You're describing the "dummy package" approach. I was advocating for
the "virtual package" approach (with version-qualified Provides <- this
is key), but yes, either approach works :) Some people find empty
packages ugly/cruft so I prefer to avoid them when possible, but it
sounds like this isn't consensus for this approach at this time. Thus,
yes, now I agree with you!
> Almost unrelated to bookworm (and so having less priority) issue: coming
> Emacs-29 will have built-in Org-9.6 and difference between versions will
> be substantial. Benefits of empty elpa-org in comparison to outdated Org
> will be more important.
>
Agreed!
Regards,
Nicholas
signature.asc
Description: PGP signature
