summaryrefslogtreecommitdiff
path: root/dh_elpa
Commit message (Collapse)AuthorAge
* add substvar for emacsen-common dependencyDavid Bremner2015-09-17
|
* do nothing if not given any files in pkg.elpa or on command lineDavid Bremner2015-09-12
|
* add check for missing foo-pkg.elDavid Bremner2015-08-23
| | | | The elisp code dies mysteriously if it isn't there
* dh_elpa: replace 'die' with 'error'David Bremner2015-08-23
| | | | This produces more standard looking messages
* add note / question about elpa-srcDavid Bremner2015-08-21
|
* use temporary directory under debian/.debhelperDavid Bremner2015-08-21
| | | | | This is a suggestion of Nils Thykier, to avoid adding special handling for keeping temporary files. This is removed by dh_clean.
* set mode of different emacsen-common pieces appropriately.David Bremner2015-07-18
| | | | Thanks lintian!
* update load pathsDavid Bremner2015-07-17
| | | | | | dh-elpa.el needs to be loaded from the "never-byte-compiled" path, but other packages might need to be loaded from the "not-yet-byte-compiled" path"
* auto-installation of helper scriptsDavid Bremner2015-07-17
| | | | | | This means no fancy predepends are needed because we just copy the scripts in at build time. Of course bug fixes for the helper scripts require package rebuilds.
* add no-byte-compile optionDavid Bremner2015-07-17
| | | | | In particular --no-byte-compile allows building dh-elpa without worrying about where to find the maintainer script helpers.
* clean up temporary directoryDavid Bremner2015-07-17
| | | | The tarball creation is reasonably well tested at this point.
* change installation target directoryDavid Bremner2015-07-16
| | | | | | | My initial plan to have both the generic install and the bytecompiled version in different places in package-directory-list didn't work out, so move the non-bytecompiled version out of the default package-directory-list.
* add minimal POD to dh_elpa, and install it as a man pageDavid Bremner2015-07-13
|
* replace dependency on File::SlurpDavid Bremner2015-07-13
| | | | Hopefully I'm doing this "read back the temp file" thing correctly
* compute elpa package name from debian binary package name.David Bremner2015-07-13
| | | | This is probably not the best solution, but it works for now.
* add function to only print command output on error.David Bremner2015-07-13
| | | | A refined version of this should perhaps be pushed into debhelper.
* Initial support for multiple-file packagesDavid Bremner2015-07-12
| | | | Still no byte compilation, and grotesque amounts of output
* minimal conversion to perl / debhelper libDavid Bremner2015-07-12
| | | | | | | | | | | | 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.
* hack to add dh-elpa.el to load-pathDavid Bremner2015-07-11
| | | | This would all be easier if I didn't insist on using emacs -Q
* use package.el magic to find the lisp fileDavid Bremner2015-07-11
| | | | | Since the whole point of this package is to simplify other packages, try to set a good example.
* make dh_elpa actually work with an installed elisp file.David Bremner2015-07-11
| | | | | This is not the most elegant solution in the world, but impovements only need to change this package's debian/rules.
* start a simple wrapperDavid Bremner2015-07-11
Scripts using emacs lisp require wizard level hackishness to get execed. Let's do things the simple way.