Nicholas D Steeves <s...@debian.org> writes: > 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] >
I tend to put everything at the end as when the mail becomes long I lost count of the links and end up having several "[1]"s :P >> [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. > Ack. As David and Sean also mentioned the long-term plan is to deprecate src:emacs-goodies-el, may be it's better to move forward in this direction for Trixie. > 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? > Emacs provides `major-mode-remap-alist' since 29, so that users can optionally choose to enable the corresponding ts mode in their liking. This makes it easy to have both non-TS and TS modes to co-exist. Functionality-wise TS modes still have a long way to catch up with existing modes so being able to have both co-installed is good for users. > 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? > If the long-term plan is to let src:emacs-goodies-el phase out, I think it makes sense to make emacs-editing-major-mode in its own source package. David, Sean, wdyt? > 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. > Ack. This sounds like a good way to inform existing users to move on. > 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. > I was also thinking about a way to advertise addons packaged in Debian. There are many resources for installing addons through package.el, and having a list of Debian ELPA packages would be useful for users. May be set up a Debian Wiki page for starters? > Cheers, > Nicholas -- Regards, Xiyue Deng
signature.asc
Description: PGP signature
