You're right about now being the time to move forward on this project, since it requires a trip through NEW :)
Xiyue Deng <manp...@gmail.com> writes: > emacs-goodies-el depends on a list of useful Emacs addons. While most > of them are useful, it is less flexible that a user would have to > install all of them even if some of the packages are not of interest. This is by design. The plan is for emacs-goodies to *not* be flexible so that users install it, evaluate what they really need, then uninstall emacs-goodies; this is part of the long-term plan to remove src:emacs-goodies-el from the archive. This is also because the bin emacs-goodies functions as a sort of maximally stable interface to the previous "bundle of foo.el bar.el files" that predate all contemporary best practices. [consider putting links near their context, because no one includes end-notes in their replies] > [1] https://salsa.debian.org/emacsen-team/emacs-goodies-el/-/merge_requests/2 NACK (to the original proposal. Email continues) Xiyue Deng <manp...@gmail.com> writes: > Sean Whitton <spwhit...@spwhitton.name> writes: > >> Hello, >> >> On Tue 01 Oct 2024 at 11:11pm -07, Xiyue Deng wrote: >> >>> I wasn't planning on doing something as dramatic as getting rid of the >>> `emacs-goodies-el' binary package yet, so maybe still keeping it until >>> after Trixie? We may announce its deprecating in `news' once we have a >>> plan. Agreed. >> We've been working towards removing it for years and there is already a >> NEWS.Debian entry written by me in 2018, apparently, implying that it's >> intended to be a transitional package. Yes, David yourself and I had an IRC conversation between 2020-2023 conversation about the middle step in the transition, and I took notes. Everyone agreed a middle transition was best for such an old package. >> So how about removing it *for* trixie? That middle step was supposed to be for bookworm and we missed the boat. > One thing I just thought to check: the popcon statistic suggests it's > still installed by over 1800 machines[1], so removing would probably > upset quite some users. Given this I'd be more inclined to keep this > for now Agreed. And don't change it! We've closed bugs from dozens of users who asked us to add other modes to either src:emacs-goodies-el or bin:emacs-goodies-el explaining that we're not adding to the package--only reducing it. We've maintained that line that policy for years and it's flaky, ignorant, or unethical to change it now, imho. Point being: Our word to our users counts for something, and this is to a bunch of users over a bunch of years. > and try to making it more flexible for now. Wdyt? Would also be > great to hear from more people. If the emacs-goodies-el package is going to stick around then it should remain frozen, except for removing broken dependencies that no one cares enough to fix in time for a release. The reason David and I didn't systematically update or "fix" it was because the package is an anachronism and is frozen and on its way out. Doing optional work on it suggests that it's not on its way out. Don't you agree, and also that such work is an irrational use of free time--which includes sponsor time? To add flexibility (ie: your proposed Recommends, which some perceive as annoying dependencies that resurrect on every upgrade), use another binary package than bin:emacs-goodies-el, including transitive dependencies. This packages is almost 24 years old and is the definition of slow-moving. Honestly, I think src:emacs-goodies-el should not be used for an "all-the-major-modes" package, because their purpose is fundamentally different. Src:emacs-goodies-el is a curated and stable list of packages, and the "all-the-major-modes" will be volatile from release to release. There's also a lot of overlap between lsp and native more tightly integrated modes. What is the plan for that? Maintenance is also not as easy as adding all packages that clear NEW, but this could be useful for discovering conflicts between packages. Also, if the objective isn't a curated list, then why wouldn't something based on https://wiki.debian.org/Debtags be more useful? Ie just do it dynamically. Also, in terms of "advertising" type things, why not patch the Welcome Page that Emacs displays (Or did we get rid of that?) rather than make emacs-goodies result in a state of emacs-glob-install-all-major-modes? Finally, if it requires a trip through NEW, why not just do a NEW src:package? As I see it, the only discussions that are related emacs-goodies-el are how to announce that users should consider switching to $convenience_packages for Forky, because src:emacs-goodies-el will be removed for this release. It may be also be worth making bin:emacs-goodies-el a documentation-only package for Trixie, but adding a new NEWS entry that says what to to install instead and/or provides debtags-based instructions. Cheers, Nicholas
signature.asc
Description: PGP signature
