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