lein_makepkg - Design/Desiderata

[Gergely Nagy]

Note: I have not read the original mail yet, so if I'm missing some
context here, sorry!

Eugenio Cano-Manuel Mendoza <eugeniocanom at gmail.com> writes:

> 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 don't see a case for clojure:Depends either. The closest thing I could
come up with as a use case were things that the java app/lib/etc would
load on-demand (think plugins), but were reusable outside of a single
app. Not sure jh_depends can catch those, but it's a rare enough case to
not care about right now, anyway. And perhaps such a case doesn't even
exist.

So, java:Depends should suffice, I think.

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

+1, grab it from project.clj/pom.xml, and leave tweaking up to the
maintainer.

>     * Regarding the Standards-version, I checked with javahelper and they
> are just written there, hardcoded. My question: How often do this actually
> change?

Rarely. And the packaging should follow Standards-Version, so hardcoding
it is okay. If and when a new policy comes out, S-V can be bumped (and
the script modified, if need be).

> Regarding compat:
>
>     * Again just like Standards-version, how often does it change?

Even less often. DH7 is still supported, DH9 is in wheezy, 10 has been
started, as far as I remember... but we're fine with sticking to 9 or so
for at least jessie. That's long enough. :)

> Watch file:
>
>     * Should be set manually and we could add an option to lein_makepkg
> where we specify upstream's repo.

Most Clojure things are hosted on github, it makes sense to default to a
github-esque watch file. However, tagging schemes tend to vary a lot, so
the watch file will likely need manual editing.

I'm not sure I'd put this in ln_makepkg... perhaps a separate tool for
the job? (can be in the same repo, just not neccessarily baked into
ln_makepkg)

-- 
|8]