Hello, On Thu, Dec 17, 2015 at 11:19:09AM +0100, Rémi Vanicat wrote: > I was wondering if it would not be the moment to ask the dash-el debian > package maintainer to switch to an elpa style package. We will have more > and more package depending on dash-el, and the sooner dash-el integrate > into the elpa infrastructure, the easier it will be for us to add new > package. On Thu, Dec 17, 2015 at 08:40:00AM -0400, David Bremner wrote: > 1) Perhaps we should start by documenting (on the wiki?) what the concrete > benefits of switching existing packages to dh-elpa. Is this mainly > easier calculation of dependencies, less changes to upstream test > suites, or ? Here's something: any package which depends on dash will have "Package-Requires: (dash (0.foo))" in its header, and this must be commented out with a quilt patch or Emacs will complain that it can't find dash. Since dash is depended on by so many packages, switching it to a dh_elpa package would save a lot of patching. > 2) Is dh-elpa feature complete? One thing we discussed in Heidelberg > that isn't implimented yet is calculating dependencies from elpa > metadata and putting them in a substvar. I think this is not so hard, > I'm curious whether people think we should try to have it in place > before pushing for wider adoption of dh-elpa. Or are there are other > important missing features? I'm planning to give this a shot. In my own view it does not block pushing for wider adoption of dh_elpa, though, because it's very easy to look up the dependencies by hand (e.g. by looking at the package's page on MELPA and then confirming by checking the main .el file). > 3) Are we willing to offer to adopt packages? My experience from the > perl team suggests this is the surest way to get things done. OTOH, you > need to be prepared to deal with a large number of packages. So far the > team is pretty loosely knit; I've just begun to sponsor packages for > team members without uploading privileges; I'm not sure if other people > are willing/interested in doing that. Sean's activities are probably a > good test for that. Perhaps we could at least offer to adopt core dependencies. There's not much point in adopting Org-mode: since an old version is part of Emacs core, I don't think any ELPA packages depend on it. On the other hand MELPA reports that 15 packages depend on magit. > 4) Another thing that has been suggested at some point is > auto-rebuilding team packages on a new dh-elpa upload. Because of the > generated maintainer scripts, this rebuilding is likely to continue to > be required, and it's not very nice for uploaders. Could you explain why this is needed, or point me somewhere to read about why? I thought that since all Emacs Lisp packages are architecture-independent there was never any rebuilding needed. Sean
Attachment:
signature.asc
Description: Digital signature