Hi,

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.
Given that APT supports Recommends, I would like propose that
emacs-goodies-el to use Recommends instead of Depends for those
packages, so that a user can choose to leave certain package uninstalled
while still benefits from other packages that this meta package
provides.

This is implemented in a MR[1], and the patch is attached.  PTAL.  TIA!

(Note that I have commit access to the repo so you can leave the merging
to me once you LGTM the patches.)

Xiyue Deng <manphiz@gmail.com> writes:

I think my original idea was to treat emacs-goodies-el as a transitional
package and have it go away eventually. If other people think it's
useful and want to maintain it, that's fine of course. In the long term
what is the relationship between a continued emacs-goodies-el and your
other proposed meta-package (emacs-editing-modes?).

d

Xiyue Deng <manphiz@gmail.com> writes:

I think my original idea was to treat emacs-goodies-el as a transitional
package and have it go away eventually. If other people think it's
useful and want to maintain it, that's fine of course. In the long term
what is the relationship between a continued emacs-goodies-el and your
other proposed meta-package (emacs-editing-modes?).

d

Hello,

Yeah, we wanted to get rid of emacs-goodies-el.

I think there is a stronger case for emacs-{editing,major}-modes.  It
seems like "just give me all the major modes" is something people would
want, and "give me a random selection of Emacs addons" or even "give me
all the Emacs addons" are not.

Hi David, Sean,

Sean Whitton <spwhitton@spwhitton.name> writes:

Thanks David, Sean for the background! 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.

Though probably it's a good time to start brainstorming.  Following
Sean's suggestion, maybe we can start with major modes, minor modes,
useful tooling (e.g. boxquote, debpaste), etc.  Suggestions welcome!

Hello,

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.

So how about removing it *for* trixie?

My thinking with major modes is that they're meant to be unobtrusive.
It's reasonable to just want all the Emacs file support Debian has
available rather than making choices.  Like installing texlive-full.

Also, it's very easy to maintain.  Whenever a new batch of major modes
make it through NEW, they can be added to the metapackage.

I'm less sure about other categories of package.  They're much more
specialised, and you're unlikely to want to use them without adding
configuration to your init.el, in which case why not just install them
individually?

Also, it might be that the list of packages falls out-of-date over time,
as trends evolve.  Whereas a way to install all the major mode supported
in Debian wouldn't ever stop being useful.

Sean Whitton <spwhitton@spwhitton.name> writes:
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 and try to making it more flexible for now.  Wdyt? Would also be
great to hear from more people.

[1] https://qa.debian.org/popcon.php?package=emacs-goodies-el

You're right about now being the time to move forward on this project,
since it requires a trip through NEW :)

Xiyue Deng <manphiz@gmail.com> writes:

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]

NACK (to the original proposal.  Email continues)

Xiyue Deng <manphiz@gmail.com> writes:

Agreed.

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.

That middle step was supposed to be for bookworm and we missed the boat.
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.
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

Hello,

It's a transition package, so this is expected.

Hello,

Reusing the emacs-goodies-el source package just seemed convenient.
Making a separate source package is fine with me.  Xiyue?

Nicholas D Steeves <sten@debian.org> writes:

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

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.

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.

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?

Ack.  This sounds like a good way to inform existing users to move on.

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?

Sean Whitton <spwhitton@spwhitton.name> writes:

Ack.  Let me make a new source package then.  Is
`emacs-editing-major-mode' good for the source package name?

[ BTW, as I mentioned I was thinking about introducing more metapackages
for various useful tools/minor modes/etc., so I would have suggested
something more generic for the source package name.  Now I think the
Debtag system Nicholas mentioned may work better, and we can also set up
a Debian Wiki page for an overview of packaged Addons in Debian, which
would also serve the purpose. ]

Hello,

Note that debtags has been sunset and is officially unmaintained.  It
might go away at any time.

How about calling it emacs-addons-metapackages just in case we want
something else some day?

Sean Whitton <spwhitton@spwhitton.name> writes:

Sounds good.  This makes the intention to only have metapackages clear.

I took the liberty to have created the repo and added
emacs-editing-major-modes[1].  I have also reverted the change in
emacs-goodies-el[2].  PTAL.

[1] https://salsa.debian.org/emacsen-team/emacs-addons-metapackages
[2] https://salsa.debian.org/emacsen-team/emacs-goodies-el/-/commit/54b3d4413eb9b7dcc80fd4c48c3af720c2e30a08

Hello,

Thanks.  Here's a review:

I think we use "Debian Emacsen team" not "Debian Emacsen Team", right?

Homepage should perhaps be a page on wiki.d.o, not the repository?

Let's not provide emacs-goodies-el.  Let's have a fresh start with this.
Leave emacs-goodies-el to the old source package.

How about adding a comment in README.Debian saying that it's a bug if
any file-editing major modes are missing from emacs-editing-major-modes?

Description should probably be "file-editing" not just "editing".

How about just using a version number of '1' and just increment it each
time we update?  (I don't mind if you do want to use 0.1.)

Sean Whitton <spwhitton@spwhitton.name> writes:

Done

Make sense.  I have temporarily removed the Homepage.  Will add back
once we have a wiki page set up.

What a silly copy-paste error.  Removed.

Added a draft, though it is very lacking (also I'm not a native
speaker), so please feel free to revise.

Done.

Changed to 1.0, and save the minor version for brown-paper-bag-bug-fix
kind of revision.

PTAL.

Hello,

I rewrote a sentence in README.Debian for clarity.  Let me know when you
want me to upload this to NEW.  Maybe you'd like to commit the 'dch -r'
commit in this case.

Sean Whitton <spwhitton@spwhitton.name> writes:

Thanks!

Done.  Please feel free to upload.  Thanks!

Hello,

Done, though unfortunately I had to make a commit to fix the
permissions of d/rules; dgit was complaining about the inconsistency.
(It's 755 in the built source package.)

Sean Whitton <spwhitton@spwhitton.name> writes:

No problem.  Thanks for the fix!  (Wondering why dgit didn't complain at
me locally :/)

Sean Whitton <spwhitton@spwhitton.name> writes:

Revisiting this.  What do we want to do with emacs-goodies-el for
Trixie?  Should we remove it or keep it in Trixie for the last time and
mention in NEWS to let people be prepared for its removal in Duke?