Hi H.-Dirk, and anyone else reading this, I just found this draft from 3 June, and am sending it now:
"H.-Dirk Schmitt" <d...@computer42.org> writes:
> For myself I have deinstalled elpa-org for the moment.
That makes sense. There's a parallel discussion at #1035650, btw, and
the current package in both sid and testing [now bookworm/stable]
has no lisp files.
> But this mitigation – or the suggested changing of the load-path –
> introducing unnecessary modifications, which will – Murphy's Law – become
> persistent.
>
> A „clean solution“ should avoid duplicated distribution of the same
> functionality – especially if one „shadows“ the other.
Can upstream be convinced of this „clean solution“? If so, then Debian
would inherit it; however, I suspect they'll reply with something like the
following:
-- Why? Emacs with bundled org-mode works fine with org-mode
installed from GNU ELPA. Also, Emacs is, by-design a distribution
of various useful libraries.
> I suggest strongly to drop the duplicated parts from the main emacs-el and
> either only distribute as 'elpa' or move to distinct packages setting
> conflicts against the elpa version (and vice versa!) .
Sorry, I don't understand what you mean by "or move to distinct
packages". I'll discuss the Breaks Provides case below.
> The problem of the duplicated 'elpa-org' distribution applies also to – on my
> system – to 'elpa-seq' and 'elpa-let-alist'.
Duplication is arguably an aesthetic concern; however, I agree with you
100% that it's a serious problem when an older version of elpa-foo
functionally shadows the Emacs built-in version. That said, aesthetic
concerns have value--sometimes great value. Is this an important enough
issue to you that you're willing to invest a significant amount of time
into continuously unbundling (within a Debian context) anything that is
added to Emacs, for the foreseeable future? You'd also need to convince
the other Debian Emacs maintainers of why this is important.
There are a couple of alternative solutions that I think ought to be
discussed. For example a script that parses our Emacs' built-in
version, and that files release critical bugs against an elpa-foo
package when it's older than the Emacs built-in version.
If a package hasn't been updated between the point when Emacs is
uploaded to Debian (before the freeze) and the point in the freeze that
"no rentry into testing" becomes enforced, then I think it's fair to say
that the package may be so insufficiently maintained that it shouldn't
be part of the upcoming release.
It's also worth considering whether this can be solved using Debian
dependencies, without making disruptive unbundling changes. Ie emacs-el
would declare breaks against things like elpa-org (<< x.y.z). In this
case, it would need a "Provides: elpa-org (x.y.z)" to not break packages
that have a hard dependency on elpa-org. I don't think it would be safe
to use unversioned Provides. A script to maintain these would need to
be written and integrated into src:emacs's build process, and the parser
for this would necessarily be similar to the RC bug filing one; It seems
like there is an opportunity for code reuse here. I wonder if having a
package with a huge list of Breaks and Provides would reveal
corner-case bugs in things like aptitude?
Best,
Nicholas
signature.asc
Description: PGP signature
