David Bremner <david@tethera.net> writes: > Note that by filing this bug with severity serious, you are proposing to > remove elpa-org from bullseye. This might be the right course of action, > I'm not sure. > At this time, this would mean that at least elpa-org-contrib will also be dropped. I don't know if there are others. IIRC elpa-org-drill doesn't depend on elpa-org at the dpkg level, so maybe that Depends (or Recommends) could be dropped from elpa-org-contrib and others? > I guess one downside is that people will just keep the old version of > elpa-org when upgrading, but at least it will show up as an obsolete > package in some package management interfaces. > Is there a practical argument against adding versioned Provides to either emacs-common or emacs-el (as appropriate)? Something like Provides: elpa-org (= 9.5.5) The idea is that emacs-common (or -el) would replace elpa-org 9.4.0+dfsg-1 from bullseye during the upgrade to bookworm, but that a future bookworm-backport (or the future trixie package) of standalone org-mode would replace the versioned semivirtual "elpa-org" package. I haven't taken the time to test to see if this would also need Breaks and replaces, because #1033400 makes it sound like the release team would necessarily stonewall any possible fix. > This bug is also duplicate of #1033400, but that bug (for now) has > different severity. Both look probably RC to me, and org-mode is a killer feature that motivates people to adopt Emacs, so imho we need to get this right. I think we need to discuss the versioned Provides approach, or some other approach, inform the release team of the situation and let them know the options we've considered, and then ask them what they'd like to see. After all, it's unlikely they'll ack a standalone elpa-org update. Regards, Nicholas
Attachment:
signature.asc
Description: PGP signature