lein_makepkg - Design/Desiderata
Wolodja Wentland
debian at babilen5.org
Fri May 31 15:15:23 UTC 2013
Hi all,
I've had a conversation with Eugenio yesterday and we discussed a number of
topics and we were both under the impression that it would be preferrable to
get started with our packaging helpers rather sooner than later. This does, in
particular, mean that the packaging involvement is reduced in favour of the
tool development.
As leiningen 2 has, as of now, not yet been packaged it makes the most sense
to start with the development of our lein_makepkg tool (or whatever we want to
call it) and I would like to scetch our requirements for this tool in this
mail. This should enable us and, in particular, Eugenio to make informed
design decisions and should also serve as an informal todo list during the
development of this helper.
In general we want lein_makepkg to work for leiningen projects like similar
tools that are used during the initial debianisation such as:
* dh_make
* jh_makepkg
* mh_make
The main source of information is, naturally, the project.clj file
and we can draw from a wealth of information there [0]. The first step during
the development should therefore be the implementation of suitable parser that
allows us to access project.clj.
I will now simply mention a couple of ideas that pop into my mind right away
and I would hope that you can add to this. We can then summarise it at the end
and make decisions regarding implementation details:
* Provide a standard CLI interface (e.g. like one from Python's argparse)
* Use typical environment variables to populate default values, but allow
these to be overwritten with suitable options
- DEBEMAIL / EMAIL
- DEBFULLNAME / NAME
… ?
* Standard files in debian/
copyright
* DEP-5 [1] compatible copyright file
* Can we populate this in a meaningful manner from :license ?
* Section for * and another one for debian/*
* debian/* section should contain the packager (as inferred from
DEBFULLNAME and DEBEMAIL, ...)
control [2]
* Should populate fields such as Source, Maintainer, Section,
Priority automatically
* Homepage: from :url (if available)
* Can we figure out actual (non-Debian) Build-Dependencies automatically?
* Build-Dependencies should already contain clojurehelper (our
packaging helper), maven-repo-helper, debhelper, javahelper and
whatever else is appropriate (default-jdk, clojure, ...)
* Binary package definition
* Depends: et al should probably be handled by javahelper's
{java:Depends}, {java:Breaks} ... as detailed in [3]
Are we likely to require anything on top of that? (e.g. do we
have need for {clojure:Depends} in there that is populated by
clojurehelper in the same way as jh_depends populates
clojurehelper in the same way as jh_depends populates
{java:Depends}
* Populate Description: with content from :description ? /
Placeholder ?
* Vcs-{Git,Browser} can be set to
- git://git.debian.org/pkg-clojure/$SOURCEPACKAGE.git
- http://git.debian.org/?p=pkg-clojure/$SOURCEPACKAGE.git
* Standards-Version:
Can we set this automagically to the latest version?
* Maintainers: Debian Clojure Maintainers <pkg-clojure-maintainers at lists.alioth.debian.org>
* Uploaders: DEBFULLNAME <DEBEMAIL>
rules
* DH7 sequence + appropriate helpers (clojurehelper, javahelper,
maven-repo-helper, ...)
* Markdown stuff for README.md that commonly comes with github
projects?
source/format
* "3.0 (quilt)" as content
changelog
* should we run "dch --create" or simply ask the user to do that?
compat
* Should be the latest debhelper compat level (e.g. "9")
Can we populate this automagically? How can we figure out the
current debhelper version to depend on or what to set compat to?
watch
* We can probably generate this from { :scm { :url ...}} but I
haven't seen that used very often
Maybe check :scm :url or :url if it is github and then generate
a suitable file, test a uscan run and then fallback to
installing a placeholder? Could just install a placeholder in
the first place and let the packager do the work though.
* Nice to have:
$pkgname.{docs,doc-base}
For documentation found in the package. Not sure how fancy we want
to be here, but maybe README{,.md,.txt,..} + content of doc/ (if
any)
$pkgname.poms
This is meant for maven-repo-helper and allows it to install a
suitable pom into the maven repository. The pom can/could be
generated with "lein pom" by clojurehelper
$pkgname.jlibs
List the jar build for this package, can we get and populate this
during the build in a meaningful way (e.g. by extracting the
information from the generated pom or something?)
That is what I can think of for now. I am not sure what the best way is to
implement this and there are several pros/cons regarding the language of
choice. I consider BASH, Python and Clojure (leiningen plugin) to be sensible
choices and slightly prefer either Python (favourite) or a leiningen plugin,
but it might be nice to be able to use some javahelper functionality directly.
Python OTOH allows us to tap into its standard lib (e.g. argparse, os, ...)
and use python-apt and/or clojure-py/hy/paultag-brain-bindings while a
leiningen plugin certainly has the advantage when it comes to parsing
project.clj and might gain us more acceptance in the Clojure community. Phil
would probably be able to help with that approach.
But lets get the requirements down first before we jump to conclusions ...
thanks for your time!
[0] https://github.com/technomancy/leiningen/blob/master/sample.project.clj
[1] http://www.debian.org/doc/packaging-manuals/copyright-format/1.0/
[2] http://www.debian.org/doc/debian-policy/ch-controlfields.html
[3] file:///usr/share/doc/javahelper/tutorial.html
--
Wolodja <debian at babilen5.org>
4096R/CAF14EFC
081C B7CD FF04 2BA9 94EA 36B2 8B7F 7D30 CAF1 4EFC
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.alioth.debian.org/pipermail/pkg-clojure-maintainers/attachments/20130531/11771f6b/attachment.pgp>
More information about the Pkg-clojure-maintainers
mailing list