Rémi Vanicat <vani...@debian.org> writes: > > 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.
Let me take this opportunity to mention a few outstanding issues / questions with the elpa-ization effort. As always, volunteers and comments are both welcome. 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 ? 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? 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. 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. I guess the first step would be to extract (somehow?) the built-using info for existing packages. In a perfect world, this would be included in a hypothetical PET instance. Unfortunately it seems there are some single-person-of-failure issues with PET, and getting an instance set up seems not so easy (never mind customizing it). 5) Currently all dh-elpa packages are non-reproducible. I haven't stared at this much, but it seems to be primarily an upstream emacs issue of using timestamps in autoloads files. The use of timestamps is not completely trivial (they are not just displayed), but I don't really know what it would take to fix. d
