lein_makepkg - Design/Desiderata
Eugenio Cano-Manuel Mendoza
eugeniocanom at gmail.com
Mon Jun 3 08:24:27 UTC 2013
Hi all,
Yes, it would be nice if we could set this straight now to avoid confusion
later on.
Regarding the control file:
* I don't think we'll need to add clojure:Depends. jh_depends seems to
be going a good job filling java:Depends so as long as we stick to that I
cannot think of any situation in which we'll have to package the jars and
not add the correct dependencies to the classpath...
* I agree we can automatically populate the package description from
description by default, is better than not writing anything at all, maybe
it can encourage clojure programers to use better :descriptions. In either
case the packager can always rewrite this :).
* Regarding the Standards-version, I checked with javahelper and they
are just written there, hardcoded. My question: How often do this actually
change?
Regarding the rules file:
* Agree with the markups but I think we should write a helper to do
this and just add it to the sequence.
Regarding the changelog:
* In my opinion we should use dch --create
Regarding compat:
* Again just like Standards-version, how often does it change?
Watch file:
* Should be set manually and we could add an option to lein_makepkg
where we specify upstream's repo.
I'm still playing with the project.clj parser to see what I like best. As
for the discussion about the debian/ files please let me know what you
think about all I said.
Cheers,
Eugenio
On Fri, May 31, 2013 at 5:15 PM, Wolodja Wentland <debian at babilen5.org>wrote:
> 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
>
> _______________________________________________
> Pkg-clojure-maintainers mailing list
> Pkg-clojure-maintainers at lists.alioth.debian.org
> https://lists.alioth.debian.org/mailman/listinfo/pkg-clojure-maintainers
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.alioth.debian.org/pipermail/pkg-clojure-maintainers/attachments/20130603/dacbe970/attachment.html>
More information about the Pkg-clojure-maintainers
mailing list