I would like to make two related suggestions regarding the way different versions of emacs are mapped to ebuilds in gentoo. Once emacs switches to bazaar this will require some work in this regard, regardless if the suggestions to follow are honored or not. So if you consider my suggestions to be worthwhile that would probably the right time to do it. Also please note that I am aware that you probably have thought about this before - maybe you have even decided to go with it already. Or you decided that it is a bad idea - then I would like to hear why. Currently two packages provide different versions of emacs: app-editors/emacs and app-editors/emacs-cvs, making a third necessary: virtual/emacs. (1) I would prefer if the development versions would be in app-editors/emacs too - with a 9999 or 50 suffix. This would make virtual/emacs unnecessary. But it would make it necessary to use more SLOTs, which would require a lot initial work, but later should require slightly less maintainence. (2) So the second suggestion is to add the minor version to SLOT and everywhere else where this is required. This would result in something like this: Package Version PV Type SLOT eselect-name emacs 22.3 22.3 released 22.3 emacs-22.3 emacs 23.1 23.1 released 23.1 emacs-23.1 emacs 23.1.50 23.1.(9999|50) cvs/bzr 23.2 emacs-(23.2|23.1.50) Installing a release candidate using portage would also be nice. Especially as this would also allow testing gentoo specifics early on. So this might be a natural addition. emacs 23.1.90 23.1.90 rc 23.2 emacs-23.1.90 As I can see the major disadvantage of my proposal is the initial work required. An advantages not mentioned so far is that it would allow to install e.g. 23.1 and 23.2 (opposed to only 23.1.50) at the same time. Which is nice for authors of elisp packages. What do you think? Reproducible: Always Steps to Reproduce:
Well, of course we have thought about this before. ;-) This is what we are _not_ going to do (at least not in the short term): - Get rid of virtual/emacs, even if it should have only one provider. As experience with the Emacs overlay shows, the virtual comes in handy in some situations. Also both maintenance cost and overhead on users' systems (where an installed virtual consists of nothing but a VDB entry) are close to zero. - There is no such concept as major/minor versions for SLOTs. The name of the slot is an opaque string, and we shall decide on a case by case basis when we'll open a new slot for a version. So far, the differences between minor versions of Emacs were always small. But we'll look at it again when 23.2 is released. Things that are discussable: - Should it be one package or two packages? I don't see much advantage for either of them. Keeping it separate might be slightly more flexible, and so far I haven't seen many users' complaints about our current scheme. - The name of the emacs-cvs package (in case we keep it separate). We can rename the package every time upstream moves to a new version control system, or we can keep emacs-cvs. What's in a name?
As far as I remember, emacs-scm came up.
(In reply to comment #2) > As far as I remember, emacs-scm came up. Yes, but in case GLEP 54 (in its current form) should be accepted that will not be a valid package name and we'll have to rename again. Which would be a nuisance for users. IMHO there's no urgent need for action.
(In reply to comment #1) First, sorry for the delay. > Well, of course we have thought about this before. ;-) I didn't expect anything else! > This is what we are _not_ going to do (at least not in the short term): > - Get rid of virtual/emacs, even if it should have only one provider. Understood. > - There is no such concept as major/minor versions for SLOTs. The name of the > slot is an opaque string, I am well aware of this. I was only suggesting that in the case of Emacs it might be a good idea to use the full version string (even though it is not "necessary") as the slot also to allow installing more versions simultaneously. > and we shall decide on a case by case basis when we'll open a new slot > for a version. So far, the differences between minor versions of Emacs > were always small. If the differences are small, then I do not understand the reason why this has to be decided case by case. One reason only to have a limited number of versions available would be that with more versions the probability of version specific bugs that would have to be taken care of would increase. But if the differences are small this seams much less likely. If the costs are not very high (which I assume, but I might be wrong) why not give the user the choice? Even if it should not make much of a difference in practice. Also you would not even have to provide this different versions in the official tree for this to be useful! If someone needs some specific version for some esoteric reason he can just copy the ebuild to an overlay and change the version suffix without having to change the SLOT also, which requires that he edits the ebuild - renaming is not enough anymore. > Things that are discussable: > - Should it be one package or two packages? I don't see much advantage for > either of them. Keeping it separate might be slightly more flexible, and so > far I haven't seen many users' complaints about our current scheme. How is this more flexible? The only flexiblity gain I can see is that both emacs-23.1-r2 and emacs-cvs-23.1.9999-r1 can be installed at the same time but using slot=version would offer exactly the same flexibility. > - The name of the emacs-cvs package (in case we keep it separate). We can > rename the package every time upstream moves to a new version control > system, or we can keep emacs-cvs. What's in a name? Renaming the package every time that Emacs moves to a new vc does not seam very appealing; then again how often is that gonna happen? But staying with -cvs would mean that the package name would be misleading. For example after the soon to take place move to bzr a user that payed attention might think that Gentoo was still using "some kind of cvs mirror" or the "old not updated anymore cvs repo" even though developement moved to bzr! This is what is in a name - information. Or in the case of a "wrong" name - confusion, that is misinformation. Because of this and of GLEP 54 I would like to see the -cvs package dropped without a replacement.
(In reply to comment #4) > One reason only to have a limited number of versions available would be that > with more versions the probability of version specific bugs that would have > to be taken care of would increase. But if the differences are small this > seams much less likely. The main reason for keeping the number of slots limited is that for some bugs (mostly security bugs, but see bug 236579 for a different example) all slots must be updated and marked stable, which means increased workload not only for us package maintainers, but also for the architecture teams. > Renaming the package every time that Emacs moves to a new vc does not seam > very appealing; then again how often is that gonna happen? But staying with > -cvs would mean that the package name would be misleading. First of all, a final decision if it should be one or two packages has not yet been made. *If* we should decide to keep an extra package for pretest and live versions, then it will be named app-editors/emacs-vcs. Rationale for this is: 1. "emacs-scm" could be misunderstood as indicating an Emacs implementation in Scheme. (This isn't so far-fetched, see "Edwin" and MIT Scheme.) 2. The Emacs manual uses "VCS" or "version control system" throughout, whereas "SCM" doesn't occur. 3. BZR calls itself a "version control system".
Emacs upstream has switched from CVS to Bazaar. Reopening.
app-editors/emacs-cvs moved to app-editors/emacs-vcs. Having it as two packages has worked well for all the years, so we (Emacs team) decided not to change it.
Reopening. Reading comment #1 10 years and 2 version control systems later, the arguments aren't compelling either way. Experience shows that keeping the two packages in sync (e.g., USE flags in metadata) needs some additional maintenance effort. Also, now might be a good time for the change, because no further releases of Emacs 26 are to be expected, and the release cycle of Emacs 27 hasn't started yet. (Alternatively, we could wait for the Emacs 27.1 release, i.e., start with the live slot for Emacs 28.) So, here's the plan: - Remove any keyworded snapshot versions from app-editors/emacs-vcs. - Copy the live ebuilds into separate slots of app-editors/emacs. (Not yet sure about the slot name, but "27-vcs" may be the most natural choice, given that the executable is already being installed as emacs-27-vcs.) - Update dependency in the eclasses from virtual/emacs to app-editors/emacs. Since we allow switching the version with eselect, this will presumably include a ":*" type slot dependency. (Future packages installing modules can use ":=" in the ebuild.) - NEED_EMACS could then include the minor version, in which case elisp-need-emacs() from elisp-common.eclass would switch to ver_test() for version comparison. - Package mask app-editors/emacs-vcs for removal. (Don't mask the virtual, but simply remove it.)
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=065156e1a42c62fdd92ba91570e6b7e1b18f8def commit 065156e1a42c62fdd92ba91570e6b7e1b18f8def Author: Ulrich Müller <ulm@gentoo.org> AuthorDate: 2019-12-17 17:56:43 +0000 Commit: Ulrich Müller <ulm@gentoo.org> CommitDate: 2019-12-18 10:06:16 +0000 app-editors/emacs: Live ebuilds copied from app-editors/emacs-vcs. The package split between app-editors/emacs for regular ebuilds and app-editors/emacs-vcs for live ebuilds has outlived its usefulness, and it entails additional maintenance effort to keep the two packages (e.g., the list of their use flags in metadata.xml) synchronised. Therefore, consolidate all GNU Emacs ebuilds in a single package. The separate app-editors/emacs-vcs package will be removed soon. Bug: https://bugs.gentoo.org/291296 Package-Manager: Portage-2.3.81, Repoman-2.3.20 Signed-off-by: Ulrich Müller <ulm@gentoo.org> app-editors/emacs/emacs-26.3.9999.ebuild | 408 ++++++++++++++++++++++++++++++ app-editors/emacs/emacs-27.0.9999.ebuild | 416 +++++++++++++++++++++++++++++++ app-editors/emacs/metadata.xml | 5 + 3 files changed, 829 insertions(+)
(In reply to Ulrich Müller from comment #8) > - Remove any keyworded snapshot versions from app-editors/emacs-vcs. > - Copy the live ebuilds into separate slots of app-editors/emacs. (Not yet > sure about the slot name, but "27-vcs" may be the most natural choice, given > that the executable is already being installed as emacs-27-vcs.) > - Update dependency in the eclasses from virtual/emacs to app-editors/emacs. > Since we allow switching the version with eselect, this will presumably > include a ":*" type slot dependency. (Future packages installing modules can > use ":=" in the ebuild.) > - NEED_EMACS could then include the minor version, in which case > elisp-need-emacs() from elisp-common.eclass would switch to ver_test() for > version comparison. > - Package mask app-editors/emacs-vcs for removal. (Don't mask the virtual, > but simply remove it.) All done. Only change is that elisp-need-emacs() has been replaced by elisp-check-emacs-version() with slightly different functionality. Keeping this bug open until removal of app-editors/emacs-vcs and virtual/emacs.
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=cb3eccbbd9baebfc96c99cd447005e4c3181a374 commit cb3eccbbd9baebfc96c99cd447005e4c3181a374 Author: Ulrich Müller <ulm@gentoo.org> AuthorDate: 2020-01-17 17:06:13 +0000 Commit: Ulrich Müller <ulm@gentoo.org> CommitDate: 2020-01-17 17:37:49 +0000 app-editors/emacs-vcs: Remove package. Bug: https://bugs.gentoo.org/291296 Signed-off-by: Ulrich Müller <ulm@gentoo.org> app-editors/emacs-vcs/emacs-vcs-27.0.9999.ebuild | 414 ----------------------- app-editors/emacs-vcs/metadata.xml | 58 ---- 2 files changed, 472 deletions(-)
For the record, I made two mistakes with Emacs 27 prereleases and release candidates (which wouldn't have happened with two separate packages, but that isn't an excuse): - While only users explicitly asking for app-editors/emacs-vcs would get any prerelease versions, these must now be explicitly package.masked. Which I did for emacs-27.0.90, but I forgot about it for emacs-27.0.91. So the latter version would be installed on "normal" users' systems, and it won't go away after the 27.1 release because it is in slot 27-vcs. Unfortunately we cannot package mask the 27-vcs, 28-vcs etc. slots because that would lead to double masking of the live ebuilds. - Ebuilds for release candidates used to be in app-editors/emacs, and following that principle, emacs-27.1_rc1 and emacs-27.1_rc2 should have been in slot 27, not 27-vcs. As a partial remedy, the following slotmoves are now in place: slotmove ~app-editors/emacs-27.0.90 27-vcs 27 slotmove ~app-editors/emacs-27.0.91 27-vcs 27 slotmove =app-editors/emacs-27.1_rc* 27-vcs 27
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=df2507b423979a04dcd7cc4d0fac17abf52232f8 commit df2507b423979a04dcd7cc4d0fac17abf52232f8 Author: Ulrich Müller <ulm@gentoo.org> AuthorDate: 2020-09-12 17:27:48 +0000 Commit: Ulrich Müller <ulm@gentoo.org> CommitDate: 2020-09-12 17:27:48 +0000 virtual/emacs: Remove package. Bug: https://bugs.gentoo.org/291296 Signed-off-by: Ulrich Müller <ulm@gentoo.org> virtual/emacs/emacs-23.ebuild | 10 ---------- virtual/emacs/emacs-24.ebuild | 10 ---------- virtual/emacs/emacs-25.ebuild | 10 ---------- virtual/emacs/emacs-26-r2.ebuild | 10 ---------- virtual/emacs/metadata.xml | 8 -------- 5 files changed, 48 deletions(-)
