You're right about now being the time to move forward on this project,
since it requires a trip through NEW :)
Post by Xiyue Dengemacs-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]
Post by Xiyue Deng[1] https://salsa.debian.org/emacsen-team/emacs-goodies-el/-/merge_requests/2
NACK (to the original proposal. Email continues)
Post by Xiyue DengPost by Sean WhittonHello,
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.
Post by Xiyue DengPost by Sean WhittonWe'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.
Post by Xiyue DengPost by Sean WhittonSo how about removing it *for* trixie?
That middle step was supposed to be for bookworm and we missed the boat.
Post by Xiyue DengOne 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.
Post by Xiyue Dengand 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