lein_makepkg - Design/Desiderata

[Gergely Nagy]

Wolodja Wentland <debian at babilen5.org> writes:

>     * Standard files in debian/
>
>         copyright
>
>             * DEP-5 [1] compatible copyright file
>             * Can we populate this in a meaningful manner from
>             :license ?

Some files have that, some don't, and it's not always uniform. It's a
reasonable guess, though. Grab :copyright with it. I'd say this would be
a nice feature to have, but by no means neccessary.

>         control [2]
>             * Can we figure out actual (non-Debian) Build-Dependencies
>             automatically?

We can look at the dependencies in pom.xml/project.clj. While not all of
those are build-deps, if there's a test suite, chances are, some of them
will be.

>             * 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}

I don't think we need clojure:Depends.

>             * Vcs-{Git,Browser} can be set to
>                 - git://git.debian.org/pkg-clojure/$SOURCEPACKAGE.git
>                 - http://git.debian.org/?p=pkg-clojure/$SOURCEPACKAGE.git

+1

>             * Standards-Version:
>               Can we set this automagically to the latest version?

Don't. Set it to a hard-coded value instead. That way, we can verify
that whatever the tool generates conforms to the hard-coded policy
version. If we automatically set S-V, we loose this ability, and that'd
be a shame. The tool should emit output that is verified to be as close
to policy compliant as possible. We can't auto-update the tool with
policy, so we shouldn't do that with S-V, either.

>         rules
>
>             * DH7 sequence + appropriate helpers (clojurehelper, javahelper,
>               maven-repo-helper, ...)

I would go with DH9 + helpers. The difference is minimal, and v9 is the
recommended mode of operation.

>             * 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?

+1

>         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?

Just go with dh9. That'll be with us for quite a while.

>         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.

The problem with this is that you can get the repo url and whatnot, but
you can't automatically get the tags right, and unfortunately, there is
no standard tagging scheme, and many projects use wildly different tags.
:/

It's a good estimation though, but perhaps as something optional or
experimental, to be enabled by a CLI flag or something?

>     * 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)

Just the bare minimum, README.*. If there's anything else, the
maintainer can add it. It'll need manual review anyway.

I'll ponder a bit about what else I'd wish the tool could do, and follow
up later.

-- 
|8]