Hello to everyone reading this, Thank you very much for replying!
On Thu, Jun 14, 2018 at 05:16:07PM -0300, David Bremner wrote: > Nicholas D Steeves <nstee...@gmail.com> writes: > > > > > I've also been wondering about Debian's xemacs support for a year, and > > the position I've formed (which Sean has confirmed) is that as a > > general case packages should be transitioned to dh-elpa. Given the > > specific case of unversioned emacs support as a team goal it seems > > clear that xemacs support should be dropped at this time. Has there > > yet been an official announcement to users that xemacs is depreciated > > in Debian? > > Well, it's a team goal, but the packages are not team packages. So it > would be nice to have some feedback from Julian or Peter here. There > has been no such announcement; I guess it would be up to either Rob as > maintainer of emacsen-common, or the xemacs maintainer. Reply a couple of lines below. On Fri, Jun 15, 2018 at 12:00:42PM +0100, Sean Whitton wrote: > > This is not up to any of us, but the Debian maintainer of xemacs. And I > do not believe he has any intention of dropping support. 10. Hm, what about the following: Each bin:$package currently in src:emacs-goodies-el becomes bin:xemacs-$package, that provides the virtual package $package. Then, to fix the unversioned Emacs bug in debian-el and dpkg-el, we fork src:emacs-goodies-el into multiple src:packages. eg: as David and I have already done. It would be nice if emacs-goodies-el provided a tarball or tag without packaging, or alternative a patches-applied git remote with a custom merge driver could be used to merge everything except emacs-goodies-el/debian. Src:various-goodies-fork/debian/control would provide the appropriate bin:elpa-various-goodies-fork; however, the source package for each of src:various-goodies-fork would unfortunately contain all of the src:emacs-goodies-el source at this time. The extraneous content can be pruned (or just git removed if preferred) at a later date as src:emacs-goodies-el is broken up (if it is broken up). Most importantly, the each bin:elpa-various-goodies-fork provides its respective virtual package. Eg, bin:elpa-debian provides bin:debian-el, which is also provided by bin:xemacs-debian-el. The one thing I'm not sure about is how to handle the upgrade path... Is there a way to prefer elpa-debian over xemacs-debian-el when both xemacs and emacs are installed? Skip to the bottom for info on the dummy transition package. > > 0. Is the Emacsen Team going to maintain all of the new packages? > > Yes, but don't forget the Policy requirement that at least one human be > listed in Uploaders. > > > If so, can Peter S Galbraith and Julian Gilbey be added to the team > > and to the Uploaders for all these new packages? > > Only if they explicitly consent to their addition to each individual > package. Alternatively, isn't it possible to add the elpa-variants to src:emacs-goodies-el? Would that be preferred at this time, and gradually break out the elpafied packages into their own src:elpafied-packages as human Uploaders volunteer? > > 3. Is the consensus is that the git history of all the new packages > > does not need to be preserved from src:emacs-goodies-el? > > On both of these issues, we've all already given you our opinions in > previous messages and/or IRC. Since you're doing the work, you get to > decide between those opinions. > > > 4. I noticed that emacs-goodies-el has not had a dependency on an > > elpafied packages added each time a file is removed. This seems to > > indicate that when this work is completed bin:emacs-goodies-el will > > just silently disappear and users will be left without the modes they > > are used to having after an upgrade. Is this intended, or should > > emacs-goodies-el become a dummy transitional package? > > Seems like an oversight. A transitional package would be useful to > users. To add to [10], xemacs-goodies-el should provide the virtual emacs-goodies-el, and elpa-goodies can also do the same? In this case elpa-goodies would be a dummy transitional package. Maybe this is an ugly and cumbersome approach, but it seems like it would be less disruptive to xemacs users and less hijacky to src:emacs-goodies-el. What does everything think? Nicholas
signature.asc
Description: PGP signature
