| Commit message (Collapse) | Author | Age |
|---|
| |
|
|
|
| |
The embedding of the version is not used, so no point in paying for
the extra complication
|
| |
|
|
| |
This should allow non elpa-$foo binary packages. It needs to be documented.
|
| |
|
|
|
|
|
|
|
|
| |
There is a debhelper mechanism for dh_* tools to embed their versions
in generated maintscripts, but our emacsen-common maintscripts are not
true maintscripts, so we can't use that mechanism.
Using a binary package field makes it possible for us to find packages
that need rebuilding without looking inside the contents of any binary
packages.
|
| |
|
|
| |
this avoids tracking the metadata in the source file
|
| | |
|
| |
|
|
| |
also depend on perl, while we're at it.
|
| |
|
|
|
| |
In particular --no-byte-compile allows building dh-elpa without
worrying about where to find the maintainer script helpers.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
It turns out this isn't $MESSY_CONFLICT_ZONE, there are rules about
writing debhelper extensions.
This is mainly cargo culting from dh_installdocs.
- compute destination directory, support multiple binary packages.
- add debian/elpa file, test the "standard" codepath. Still not very
standard because it's a single file elpa package.
|
| |
|
|
|
| |
Since the whole point of this package is to simplify other packages,
try to set a good example.
|
| |
|
|
|
| |
This is not the most elegant solution in the world, but impovements
only need to change this package's debian/rules.
|
| |
|
