#1001131 [RFC PATCH] Enhance docs with answers for common questions

Package:
dh-elpa
Source:
dh-elpa
Submitter:
Nicholas D Steeves
Date:
2021-12-21 20:06:03 UTC
Severity:
normal
Tags:
#1001131#5
Date:
2021-12-05 00:53:50 UTC
From:
To:
Hello,

I've noticed that these questions are still coming up on
#debian-emacs, so I thought I'd work on a documentation enhancement
proposal.  I've attached a patch series, and--if preferred--a git remote is available at: https://salsa.debian.org/sten/dh-elpa.git

The commit messages further information, and short changelog messages
have also been provided.

Thanks,
Nicholas

#1001131#12
Date:
2021-12-07 12:39:12 UTC
From:
To:
Nicholas D Steeves <sten@debian.org> writes:

Overall this seems like a good idea. I have a few suggestions.

- I did wonder if all of "legacy-style" discussion should be
  together, perhaps under a subheading.
- it might be useful to define "legacy-style"
- I tripped over "neglegible to zero", perhaps replace with something
  simpler like "minimal".

- "maintscripts" seems a bit jargony, and the real point is that the
  packager does not need to maintain emacsen-common install/remove
  scripts. However, maybe it is better to be concise than precise here.

- The phrase "consistent with a better user experience" sounds quite a
  bit overcomplicated and overqualified.

I guess for an audience of debian contributors foo is OK, but I guess if
possible it would be nice to have something a bit less in-jokey. I don't
know if it's a strict improvement, but "hello" would be consistent with
other docs.

d

#1001131#17
Date:
2021-12-21 20:00:39 UTC
From:
To:
Hi David,

Thank you for replying quickly, and sorry for the tardiness of mine.
Holiday season, you know? ;-)

David Bremner <david@tethera.net> writes:
[snip]

Thanks!

I've been wondering that too :-)  I hope some ideas for the name of that
subheading will emerge in the course of this discussion.

Would referring to /usr/share/doc/emacsen-common/debian-emacs-policy.gz
do the trick?

More broadly, Policy §11.10 maintains that this Emacs Policy is still
the standard, while lintian complains that packages should migrate to
dh-elpa.  I suspect this is a source of confusion, but at the same time
we don't want to throw Rob (and his excellent documentation) under the
bus.

Fair point!  Likewise, it appears that the onus is on us to make a case
for dh-elpa vis à vis debian-emacs-policy.  What would you suggest would
communicate "less than minimal"?  The impression I've gotten from other
maintainers of legacy/maintscript/debian-emacs-policy packages is that
their packages work fine with minimal maintenance burden, so I think we
need to say something that communicates that dh-elpa saves time/future
headaches vs the existing status quo.

It might also be worth referencing dh_elpa_test, and expanding those
docs to expand on the value of the autopkgtests that using it enables.

Good point, and yes, I'm not sure.  The phrase used in the doc
referenced above is "maintainer scripts".

Yeah, I suppose that phrase is a bit marketing-speak ;-) To be honest
I'm not sure what precise point to make here, because I'm not sure that
most users will mix dh-elpa packages with user-specific ELPA/MELPA ones,
and because the expectation in a Debian-context is that users don't have
to worry about dependency resolution...so additional package.el
dependency checks might not add a tonne of practical value for users.  I
feel like, here, there's a fine line between a tangential and an
orthogonal explanation.

For example, it would be cool if package.el could prompt the user to
resolve ELPA-level dependencies with elpa-foo.deb via one of the
interfaces to apt, and fall back to ELPA/MELPA repos if the user can't
get root.  The use case for this would be when installing a leaf package
from ELPA/MELPA, but to fulfill its deps with apt.

What would you suggest?
https://salsa.debian.org/sten/dh-elpa.git

No rush to reply :-)
Merry Christmas!

Nicholas