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