Bug#1033400: elpa-org: Bookworm emacs 28 has org-mode included in newer version as provided here.
On 06/07/2023 06:02, Nicholas D Steeves wrote: "H.-Dirk Schmitt" writes: 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 I remember correctly, Richard Stallman considers Org mode as an important part of Emacs. On the other hand there are users who prefer to have Org newer than built-in version, fortunately it is developed in a separate repository. I am unsure that it is reasonable to split Emacs Debian package into a squad of smaller ones if an elpa-* counterpart is available. Perhaps it is easier to review elpa-* packages after packaging of new Emacs versions. I do not see much sense in painstakingly avoiding load shadowing. 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. package.el is created for interactive usage (`list-packages'), so the script will have to rely on internal variable and functions. When the package source file is known, `lm-header' may be used to obtain specific fields. It is doable, but unlikely straightforward. P.S. Thanks for packaging of Org-9.6. I did not notice the experimental package.
Bug#1033400: elpa-org: Bookworm emacs 28 has org-mode included in newer version as provided here
Hi Max, Max Nikulin writes: > Thank you for fixing of the https://bugs.debian.org/1035650 bug that was > a duplicate of this one. I am glad to see that a dummy elpa-org package > has been landed to bookworm. > > Have you decided to keep this issue open to package Org-9.6 and to > implement emacs-pkg-* provides or it was just forgotten in the changelog > message and it should be closed? Fixed in experimental, and the bug will be closed when an updated version of org-mode is uploaded to unstable. At this time, "and to implement emacs-pkg-* provides" is not part of importing a new upstream release of Org. As for all the other ideas about how things can be done better? Debian is a do-ocracy. Anyone who cares enough to invest their time to maintain a solution in the long-term is welcome to upgrade the status quo :) "long-term" is key, because a drive-by set of changes that makes things maintenance more labour-intensive is unlikely to be seen in a favourable light. Regards, Nicholas signature.asc Description: PGP signature
Bug#1033400: elpa-org: Bookworm emacs 28 has org-mode included in newer version as provided here.
Hi H.-Dirk, and anyone else reading this, I just found this draft from 3 June, and am sending it now: "H.-Dirk Schmitt" 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
Bug#1033400: elpa-org: Bookworm emacs 28 has org-mode included in newer version as provided here
Thank you for fixing of the https://bugs.debian.org/1035650 bug that was a duplicate of this one. I am glad to see that a dummy elpa-org package has been landed to bookworm. Have you decided to keep this issue open to package Org-9.6 and to implement emacs-pkg-* provides or it was just forgotten in the changelog message and it should be closed?
Bug#1033400: elpa-org: Bookworm emacs 28 has org-mode included in newer version as provided here.
For myself I have deinstalled elpa-org for the moment. 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. 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!) . The problem of the duplicated 'elpa-org' distribution applies also to – on my system – to 'elpa-seq' and 'elpa-let-alist'.
Bug#1033400: elpa-org: Bookworm emacs 28 has org-mode included in newer version as provided here.
Le samedi 25 mars 2023 à 12:40, Sean Whitton a écrit : Hello, We can't make either of these metadata changes now the freeze has begun. After the freeze, the correct fix is to just update elpa-org to the latest release. It's unfortunate that we didn't update elpa-org in time. Sorry about that. In the meantime, if you want your emacs to load the org provided with emacs-el, and not the one provided with elpa-org, you may modify the `load-path` variable. It should contain both : - "/usr/share/emacs/site-lisp/elpa/org-9.5.2" - "/usr/share/emacs/28.2/lisp/org" Since the first one comes before the other in the list, it is the one loaded when you do "(require 'org)". You'll need to make sure to have the one you want coming before the other *at the moment you require the package*. Best, Aymeric
Bug#1033400: elpa-org: Bookworm emacs 28 has org-mode included in newer version as provided here.
Hello, We can't make either of these metadata changes now the freeze has begun. After the freeze, the correct fix is to just update elpa-org to the latest release. It's unfortunate that we didn't update elpa-org in time. Sorry about that. -- Sean Whitton
Bug#1033400: elpa-org: Bookworm emacs 28 has org-mode included in newer version as provided here.
Package: elpa-org Version: 9.5.2+dfsh-4 Severity: normal X-Debbugs-Cc: none, H.-Dirk Schmitt The *emacs-el* package (source: emacs) has org-mode 9.5.5. The *elpa-org* package hast org-mode in the older version 9.5.2. This is not a cosmetic problem. In emacs M-x `org-version` shows that the „outdated“ elpa-org package is used. I suggest that either emacs-el or elpa-org package should set a conflict againt the other package. -- System Information: Debian Release: 12.0 APT prefers testing-security APT policy: (600, 'testing-security'), (600, 'testing'), (500, 'stable-security'), (99, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.1.0-6-amd64 (SMP w/8 CPU threads; PREEMPT) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE=de_DE:de:en_US:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) Versions of packages elpa-org depends on: ii dh-elpa-helper 2.0.16 ii elpa-htmlize1.56-1 ii emacsen-common 3.0.5 Versions of packages elpa-org recommends: ii emacs 1:28.2+1-13 ii emacs-gtk [emacs] 1:28.2+1-13 Versions of packages elpa-org suggests: pn ditaa pn org-mode-doc ii texinfo6.8-6+b1 ii texlive-fonts-recommended 2022.20230122-2 ii texlive-latex-extra2022.20230122-2 -- no debconf information
