Re: Wishlist bug for repackaging of dash-el ? (Was Re: Cask & dependencies)
Rémi Vanicat <vanicat@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
Reply to: