On 2016-12-30 00:11 +0100, Markus Koschany wrote:
> On 29.12.2016 02:29, Wookey wrote:
> Don't try to hard to make mh_make happy because it can only give you a
> rudimentary skeleton debian directory. (For "easy" packages it works
> much better but more complicated projects won't work as expected). We
> usually use existing packages, which are quite similar, as templates.
OK, but to do it without mh_make requires me to get a much better
understanding of the files it produces:
maven.cleanIgnoreRules
maven.ignoreRules
maven.publishedRules
maven.rules
And maven-debian-helper doesn't have a README or any manpages. Where
are the docs that explain which mh_ commands use which of those files
and exactly what the lines mean, what the fields are and so on? I can
stab about in the dark but this stuff works much better if one reads
the docs and has at least some idea what one is doing, IME.
Do I not get a control and rules file because I'm getting errors and
mh_make is not getting to the end? (Yes, I copied some from another
maven java package, but they may well be wrong)
> > I also got the complaint that it can't find:
> > backport-util-concurrent
> >
> > Do I care about that? Do I need to package that too? <sinking feeling emoji>
>
> Welcome to Java hell ^-^
yeah - see my next message in the thread with some more detail on that.
> > Also how does this 'debian' version thing work? Is that like saying
> > 'generic/current' version? And we do that to deal with all these
> > packages asking for a specific version when they really don't actually
> > care (probably). So should I prefer to set the versions for all this
> > stuff to 'debian' as that's likely to stay working for longer?
>
> Java is version centric, that means you have to declare that your
> software project works exactly with a specified version and if you try
> an older or newer one you are basically on your own. :/ As you know in
> Debian we try to package only one version of software project X and thus
> we need to use a generic "debian" version (and patch packages that don't
> work with it).
>
> The debian tools (maven-debian-helper) always rewrite the version to
> "debian" by default. You don't have to change anything here.
But mh_make asks me if I want to set the vers to 'debian' everywhere,
or not. And the default isn't always 'use debian', although it usually
is.
> There are a few libraries which are known to horribly break
> things. Here we use a substitution rule like 1.x for versions
> ranging from 1.0 to 1.99 etc, instead of using the generic
> "debian" version because we know that version 2.x will break the
> package.
OK. That makes sense. But I'm not sure that it explains the issue I had
with libbcel simply not being found, even when it was present.
> I guess it would be easier if you gave me some link to your package and
> I try to figure out why it fails for you at the moment. Please also
> describe what you want to achieve, so that I get the bigger picture and
> if you're lucky I might be able to explain why it didn't work as expected.
What I am trying to achieve is package the current (2 years ago)
caveconverter release. Which has led me to down this tree:
caveconverter
(java-diff-utils ITP#845471|libdiffutils-java ITP#696165)
jscience ITP#812562
geoapi ITP#812563
javolution ITP#833024
maven-native ITP#700679
backport-util-concurrent
I have lots of versions of my package, one 1.0-alpha-2 and two goes at
1.0-alpha-8. All three have slightly different issues.
tarball here: http://wookware.org/files/java-maven-mess.tar.gz
Wookey
--
Principal hats: Linaro, Debian, Wookware, ARM
http://wookware.org/
Attachment:
signature.asc
Description: Digital signature