Hi Cyril, Cyril Brulebois <kibi@debian.org> writes: > Hi, > > Xiyue Deng <manphiz@gmail.com> (2025-06-26): >> The same way. Say someone installed elpa-eglot from Bookworm, and tried >> to upgrade to Trixie. Now that elpa-eglot has been removed in Trixie, >> the old version will continue to exist, and cause issues. The same goes >> for other removed packages that are bundled. It would be better to have >> them removed using this trick. > > (Random backports subscriber here) > > I'm not sure I'd call that a trick. > Right, I meant to type "trick" :) > AFAICT the Conflicts/Replaces pair is pretty normal when a binary package > needs to go away (usually when its contents and/or features are merged > into/shipped by another package). Since we're talking about end-user > packages here, I assume having a Provides (versioned or not) isn't really > required (unless you want to maintain the status quo for people who would > be deploying such packages automatically, via meta packages, via Ansible, > etc.). > Thanks for confirming the use case! Just want to add that Provides is also desired to have smooth upgrades path for other externally packaged Emacs addons. Taking elpa-org as an example, which has several reverse dependencies, some of which may require newer version than the one bundled (currently 9.7.11), and the current external elpa-org has 9.7.29 that satisfies those. When a future Emacs updates contains a more up-to-date version of elpa-org (say 9.7.40), it can uninstall the external elpa-org to avoid it being shadowed, until the external elpa-org is upgraded to even more recent versions. > Not speaking for the release team, that looks like something that should > if not must be addressed to ensure smooth upgrades from Debian 12. > Ack. > > Cheers, > -- > Cyril Brulebois (kibi@debian.org) <https://debamax.com/> > D-I release manager -- Release team member -- Freelance Consultant -- Regards, Xiyue Deng
Attachment:
signature.asc
Description: PGP signature