Re: Wishlist bug for repackaging of dash-el ? (Was Re: Cask & dependencies)
David Bremner <firstname.lastname@example.org> writes:
> Rémi Vanicat <email@example.com> 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
> 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 ?
I feel that dh-elpa package need less work by packager, as most of the
packaging as been done upstream.
It also fix the problem of double installation system/user: I've 2
version of dash on my computer, one from the debian package, and one
that came as dependency of some elpa package I've installed.
> 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?
The "wrote the dependency" part didn't seem very difficult to do by
hand. That said it's an interesting feature, but it will probably
introduce new bug.
> 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.
I've some time to devote to Debian packaging, but not much. That said I
will take time to ensure package in the team are in good shape.
By the way, I converted magit to dh-elpa, but I didn't move its Debian
git repository (it still in collab-maint). Should I move it? Otherwise
we should add a wiki page on package not in the team git's repository.
> 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.
Are non dh-elpa Emacs debian package reproducible? I believe they are
not (I might be wrong), so we don't lose much by switching. That said It
would be best if the change was made before too many package are
converted, as it will certainly require a rebuild.