Xiyue Deng <manphiz@gmail.com> writes: > [...] > > But I agree removing compat-el too soon may cause unnecessary work, > e.g. NEW queue, etc. I guess maybe we can just keep this bug open and > keep compat-el out of Forky for now, and see how it will progress with > future Emacs releases. > Apparently I missed the fact that removing compat-el from testing will also remove all its reverse dependencies, which is already happening[1]. I think one easy way to solve this is to make compat-el a dummy package that depends on Emacs. This is slightly more than a workaround as it's function is indeed fulfilled by Emacs already. The same can be done to other packages that has lower versions than provided by Emacs. An alternative is to let dh-elpa generate the dependencies on compat (and other packages) that are provided by Emacs to have emacs as an alternative. This has the downside that all emacs packages need to be rebuilt and IIRC we don't have binNMU for arch:all packages, and it can be tricky to handle version bumps, e.g. when the required package version is higher than the one provided by Emacs, and when an updated Emacs provides a package higher than required version. I'd prefer the first easier solution. Would like to hear the opinions from others. [1] https://tracker.debian.org/pkg/compat-el >> >> -- >> Sean Whitton > > -- > Regards, > Xiyue Deng -- Regards, Xiyue Deng
Attachment:
signature.asc
Description: PGP signature