Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.bugs.dist > #1214771 > unrolled thread

Bug#1083073: emacs-goodies-el: Use Reccommends instead of Depends to provide more flexibility in choosing packages

Back to article view | Back to linux.debian.bugs.dist

Contents

  Bug#1083073: emacs-goodies-el: Use Reccommends instead of Depends to provide more flexibility in choosing packages Xiyue Deng <manphiz@gmail.com> - 2024-10-01 03:30 +0200
    Bug#1083073: emacs-goodies-el: Use Reccommends instead of Depends to provide more flexibility in choosing packages David Bremner <david@tethera.net> - 2024-10-01 13:00 +0200
      Bug#1083073: emacs-goodies-el: Use Reccommends instead of Depends to provide more flexibility in choosing packages Sean Whitton <spwhitton@spwhitton.name> - 2024-10-01 17:40 +0200
        Bug#1083073: emacs-goodies-el: Use Reccommends instead of Depends to provide more flexibility in choosing packages Xiyue Deng <manphiz@gmail.com> - 2024-10-02 08:20 +0200
          Bug#1083073: emacs-goodies-el: Use Reccommends instead of Depends to provide more flexibility in choosing packages Sean Whitton <spwhitton@spwhitton.name> - 2024-10-02 08:50 +0200
            Bug#1083073: emacs-goodies-el: Use Reccommends instead of Depends to provide more flexibility in choosing packages Xiyue Deng <manphiz@gmail.com> - 2024-10-18 00:30 +0200
              Bug#1083073: emacs-goodies-el: Use Reccommends instead of Depends to provide more flexibility in choosing packages Nicholas D Steeves <sten@debian.org> - 2024-10-18 03:40 +0200
                Bug#1083073: emacs-goodies-el: Use Reccommends instead of Depends to provide more flexibility in choosing packages Sean Whitton <spwhitton@spwhitton.name> - 2024-10-18 06:40 +0200
                  Bug#1083073: emacs-goodies-el: Use Reccommends instead of Depends to provide more flexibility in choosing packages Xiyue Deng <manphiz@gmail.com> - 2024-10-18 07:30 +0200
                    Bug#1083073: emacs-goodies-el: Use Reccommends instead of Depends to provide more flexibility in choosing packages Sean Whitton <spwhitton@spwhitton.name> - 2024-10-18 11:40 +0200
                      Bug#1083073: emacs-goodies-el: Use Recommends instead of Depends to provide more flexibility in choosing packages Xiyue Deng <manphiz@gmail.com> - 2024-10-19 03:30 +0200
                        Bug#1083073: emacs-goodies-el: Use Recommends instead of Depends to provide more flexibility in choosing packages Sean Whitton <spwhitton@spwhitton.name> - 2024-10-20 07:40 +0200
                Bug#1083073: emacs-goodies-el: Use Reccommends instead of Depends to provide more flexibility in choosing packages Xiyue Deng <manphiz@gmail.com> - 2024-10-18 07:20 +0200
              Bug#1083073: emacs-goodies-el: Use Reccommends instead of Depends to provide more flexibility in choosing packages Sean Whitton <spwhitton@spwhitton.name> - 2024-10-18 06:40 +0200
    Bug#1083073: emacs-goodies-el: Use Recommends instead of Depends to provide more flexibility in choosing packages Sean Whitton <spwhitton@spwhitton.name> - 2024-10-20 11:30 +0200
    Bug#1083073: emacs-goodies-el: Use Recommends instead of Depends to provide more flexibility in choosing packages Sean Whitton <spwhitton@spwhitton.name> - 2024-10-20 13:10 +0200

#1214771 — Bug#1083073: emacs-goodies-el: Use Reccommends instead of Depends to provide more flexibility in choosing packages

[Multipart message — attachments visible in raw view] — view raw

Package: emacs-goodies-el
Version: 42.5
Severity: wishlist

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.)

-- System Information:
Debian Release: 12.7
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 6.1.0-25-amd64 (SMP w/16 CPU threads; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

[1] https://salsa.debian.org/emacsen-team/emacs-goodies-el/-/merge_requests/2

-- 
Xiyue Deng

[toc] | [next] | [standalone]

#1214793

Xiyue Deng <manphiz@gmail.com> writes:

> Package: emacs-goodies-el
> Version: 42.5
> Severity: wishlist
>
> 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.)
>

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

[toc] | [prev] | [next] | [standalone]

#1214810

Hello,

On Tue 01 Oct 2024 at 07:43am -03, David Bremner wrote:

> 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?).

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.

-- 
Sean Whitton

[toc] | [prev] | [next] | [standalone]

#1214861

Hi David, Sean,

Sean Whitton <spwhitton@spwhitton.name> writes:

> Hello,
>
> On Tue 01 Oct 2024 at 07:43am -03, David Bremner wrote:
>
>> 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?).
>
> 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.
>

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!

> -- 
> Sean Whitton

-- 
Xiyue Deng

[toc] | [prev] | [next] | [standalone]

#1214866

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.

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?

> 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!

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

[toc] | [prev] | [next] | [standalone]

#1216715

[Multipart message — attachments visible in raw view] — view raw

Sean Whitton <spwhitton@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.
>
> 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?
>

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 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

-- 
Regards,
Xiyue Deng

[toc] | [prev] | [next] | [standalone]

#1216724

[Multipart message — attachments visible in raw view] — view raw

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:

> 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 <manphiz@gmail.com> writes:

> Sean Whitton <spwhitton@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

[toc] | [prev] | [next] | [standalone]

#1216730

[Multipart message — attachments visible in raw view] — view raw

Hello,

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

-- 
Sean Whitton

[toc] | [prev] | [next] | [standalone]

#1216733

[Multipart message — attachments visible in raw view] — view raw

Sean Whitton <spwhitton@spwhitton.name> writes:

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

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. ]

-- 
Regards,
Xiyue Deng

[toc] | [prev] | [next] | [standalone]

#1216745

[Multipart message — attachments visible in raw view] — view raw

Hello,

On Thu 17 Oct 2024 at 10:22pm -07, Xiyue Deng wrote:

> Sean Whitton <spwhitton@spwhitton.name> writes:
>
>> Hello,
>>
>> Reusing the emacs-goodies-el source package just seemed convenient.
>> Making a separate source package is fine with me.  Xiyue?
>>
>
> 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. ]

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

[toc] | [prev] | [next] | [standalone]

#1216882 — Bug#1083073: emacs-goodies-el: Use Recommends instead of Depends to provide more flexibility in choosing packages

[Multipart message — attachments visible in raw view] — view raw

Sean Whitton <spwhitton@spwhitton.name> writes:

> Hello,
>
> On Thu 17 Oct 2024 at 10:22pm -07, Xiyue Deng wrote:
>
>> Sean Whitton <spwhitton@spwhitton.name> writes:
>>
>>> Hello,
>>>
>>> Reusing the emacs-goodies-el source package just seemed convenient.
>>> Making a separate source package is fine with me.  Xiyue?
>>>
>>
>> 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. ]
>
> 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?
>

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.

> -- 
> Sean Whitton

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

-- 
Regards,
Xiyue Deng

[toc] | [prev] | [next] | [standalone]

#1217029 — Bug#1083073: emacs-goodies-el: Use Recommends instead of Depends to provide more flexibility in choosing packages

[Multipart message — attachments visible in raw view] — view raw

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

[toc] | [prev] | [next] | [standalone]

#1216731

[Multipart message — attachments visible in raw view] — view raw

Nicholas D Steeves <sten@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 <manphiz@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 <manphiz@gmail.com> writes:
>
>> Sean Whitton <spwhitton@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

[toc] | [prev] | [next] | [standalone]

#1216729

[Multipart message — attachments visible in raw view] — view raw

Hello,

On Thu 17 Oct 2024 at 03:20pm -07, Xiyue Deng wrote:

> 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 and try to making it more flexible for now.  Wdyt? Would also be
> great to hear from more people.

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

-- 
Sean Whitton

[toc] | [prev] | [next] | [standalone]

#1217046 — Bug#1083073: emacs-goodies-el: Use Recommends instead of Depends to provide more flexibility in choosing packages

[Multipart message — attachments visible in raw view] — view raw

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

[toc] | [prev] | [next] | [standalone]

#1217071 — Bug#1083073: emacs-goodies-el: Use Recommends instead of Depends to provide more flexibility in choosing packages

[Multipart message — attachments visible in raw view] — view raw

Hello,

On Sun 20 Oct 2024 at 02:56am -07, Xiyue Deng wrote:

> Please feel free to upload.  Thanks!

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

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.bugs.dist

csiph-web