Philipp Matthias Hahn <pmhahn@debian.org> writes:
> 1. Only in the final debian/jspwiki/ tree (but build with the original
> .jar files)
> 2. Each time during the debian/rules run
> 3. Once in the .orig.tar.gz (the download is only availabe as .zip)

You can either modify the .orig.tar.gz not to include the jars, or,
IMO a better choice, modify the building process to use the Debian
provided jars. I personally prefer keeping the orig.tar.gz as close to
the original as possible (for JSPWiki all the Debian package does is
repackage the zip as a tar.gz).

This process produces a nice and clean build process with the existing
debian/rules file.

> the files in lib/ are. I'm not aware of any other Debian package
> shipping them also, so is it okay to include them in jspwiki only or do
> I need to split them into their own packages?

If you are planning on doing a NMU then you need to split those out
and package them separately. All Debian packages must contain
buildable source for all code, and considering the JSPWiki package
doesn't contain source for the extra libraries, it is far better to
package them separately. If those libraries really aren't included in
Debian, 2.6.3 won't be packaged very soon by me.

> Also, if I strip those .jar-files from the .orig.tar.gz, do I still need
> to keep their copyright and license-info in debian/copyright?

No.

--
* Sufficiently advanced magic is indistinguishable from technology (T.P) *
* PGP public key available @ http://www.iki.fi/killer *


--
To UNSUBSCRIBE, email to debian-java-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Hello!

On Thu, Jul 17, 2008 at 01:59:36PM +0300, Kalle Kivimaa wrote:
> Philipp Matthias Hahn <pmhahn@debian.org> writes:
> > 1. Only in the final debian/jspwiki/ tree (but build with the original
> > .jar files)
> > 2. Each time during the debian/rules run
> > 3. Once in the .orig.tar.gz (the download is only availabe as .zip)
>
> You can either modify the .orig.tar.gz not to include the jars, or,
> IMO a better choice, modify the building process to use the Debian
> provided jars. I personally prefer keeping the orig.tar.gz as close to
> the original as possible (for JSPWiki all the Debian package does is
> repackage the zip as a tar.gz).
>
> This process produces a nice and clean build process with the existing
> debian/rules file.

$ du -skh lib tests/lib .
3,9M lib
7,5M tests/lib
21M .

Yes, but more than halve the source consists of files Debian shouldn't
ship, because the source for those 11 MB .jar-files isn't included with
the JSPWiki source .zip file.

> > the files in lib/ are. I'm not aware of any other Debian package
> > shipping them also, so is it okay to include them in jspwiki only or do
> > I need to split them into their own packages?
>
> If you are planning on doing a NMU then you need to split those out
> and package them separately. All Debian packages must contain
> buildable source for all code, and considering the JSPWiki package
> doesn't contain source for the extra libraries, it is far better to
> package them separately. If those libraries really aren't included in
> Debian, 2.6.3 won't be packaged very soon by me.

Sorry, but 2.5.139 already violates this rule. The following .jar-files
marked with * don't have a source in Debian (as far as I know), + is an
older version of the one in Debian.

$ dpkg -c jspwiki_2.5.139-1.1_all.deb | awk '/.jar/ { print $6; }'
* ./usr/share/jspwiki/WEB-INF/lib/freshcookies-security-0.54.jar
./usr/share/jspwiki/WEB-INF/lib/oro.jar
* ./usr/share/jspwiki/WEB-INF/lib/jug-lgpl-2.0.0.jar
* ./usr/share/jspwiki/WEB-INF/lib/mail.jar
./usr/share/jspwiki/WEB-INF/lib/nekohtml.jar
* ./usr/share/jspwiki/WEB-INF/lib/multipartrequest.jar
./usr/share/jspwiki/WEB-INF/lib/log4j-1.2.14.jar
./usr/share/jspwiki/WEB-INF/lib/lucene-highlighter.jar
* ./usr/share/jspwiki/WEB-INF/lib/ecs.jar
* ./usr/share/jspwiki/WEB-INF/lib/akismet-java-1.02.jar
* ./usr/share/jspwiki/WEB-INF/lib/jsonrpc-1.0.jar
* ./usr/share/jspwiki/WEB-INF/lib/jakarta-tablibs-standard-1.1.2.jar
./usr/share/jspwiki/WEB-INF/lib/jdom.jar
./usr/share/jspwiki/WEB-INF/lib/commons-httpclient-3.0.1.jar
+ ./usr/share/jspwiki/WEB-INF/lib/xmlrpc.jar
./usr/share/jspwiki/WEB-INF/lib/lucene.jar
./usr/share/jspwiki/WEB-INF/lib/jaxen.jar
./usr/share/jspwiki/WEB-INF/lib/commons-codec-1.3.jar
./usr/share/jspwiki/WEB-INF/lib/activation.jar
./usr/share/jspwiki/WEB-INF/lib/JSPWiki.jar
* ./usr/share/jspwiki/WEB-INF/lib/jrcs-diff.jar
./usr/share/jspwiki/WEB-INF/lib/oscache.jar
./usr/share/jspwiki/WEB-INF/lib/commons-lang-2.0.jar
* ./usr/share/jspwiki/WEB-INF/lib/sandler.jar
* ./usr/share/jspwiki/WEB-INF/lib/jakarta-taglibs-jstl-1.1.2.jar
./usr/share/jspwiki/applets/wikiwizard.jar

BYtE
Philipp
--
Philipp Matthias Hahn <pmhahn@debian.org>
GPG/PGP: 9A540E39 @ keyrings.debian.org


--
To UNSUBSCRIBE, email to debian-java-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Hi Kalle,

Kalle Kivimaa schrieb:

You can either modify the .orig.tar.gz not to include the jars, or,
IMO a better choice, modify the building process to use the Debian
provided jars. I personally prefer keeping the orig.tar.gz as close to
the original as possible (for JSPWiki all the Debian package does is
repackage the zip as a tar.gz).


What do you mean by "modify the build process". Do you mean:
1) Strip out all upstream binaries at the beginning of the build process
and use references to Debian jars instead?
2) Leave upstream binaries and only manipulate classpath to "work
around" upstream binaries?


If you use 1)
- How do you get your deleted binaries back in during clean phase? AFAIK
clean target has to reverse all changes the build process introduced.


If you use 2)
- I find this procedure rather dangerous in practice as java build
processes tend to involve complex classpath issues. It is probable that
you cannot identify all the places where a jar file gets referenced
during build. If you overlook anything you'd be in breach of Debian policy.


As long as the initial cleansing of the source tarball is automated,
simple and reproducible I do not consider this a very far departure from
the original source. IMO you don't modify the source at all you just
strip binaries which are not part of the source anyway. (And you keep
source package downloads considerable smaller for those who have a
250k-emerging-market-country internet access as I do ;-) ).


Regards,

Florian


--
To UNSUBSCRIBE, email to debian-java-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Hi Philipp,


Sorry, but 2.5.139 already violates this rule. The following .jar-files
marked with * don't have a source in Debian (as far as I know), + is an
older version of the one in Debian.


If this is the case then the package seems to violate DFSG (see [0]) and
should be included into the non-free category (see [1]) unless all these
binaries will be split off and built from (DFSG-compliant) sources.


Florian

[0] http://www.debian.org/doc/debian-policy/ch-archive.html#s-dfsg
[1] http://www.debian.org/doc/debian-policy/ch-archive.html#s-non-free


--
To UNSUBSCRIBE, email to debian-java-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Philipp Matthias Hahn <pmhahn@debian.org> writes:
> Sorry, but 2.5.139 already violates this rule. The following .jar-files

Yes, and as you may have noticed, I have already filed a serious bug
against JSPWiki because of this. Most likely JSPWiki will move back to
contrib, at least for now, as some of the libraries required are also
in contrib (eg. oscache).

--
* Sufficiently advanced magic is indistinguishable from technology (T.P) *
* PGP public key available @ http://www.iki.fi/killer *


--
To UNSUBSCRIBE, email to debian-java-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Florian Grandel <jerico.dev@gmail.com> writes:
> If you use 1)
> - How do you get your deleted binaries back in during clean phase?
> AFAIK clean target has to reverse all changes the build process
> introduced.

Easiest way to do this is to move the libraries somewhere else for
build, and then back either at the end of build or only in clean.

> If you use 2)
> - I find this procedure rather dangerous in practice as java build
> processes tend to involve complex classpath issues. It is probable

You are right, and as you probably have already noticed, I failed on
this - I had taken out only the servlet.jar but other binary-only jars
are being used in the Debian package...

> As long as the initial cleansing of the source tarball is automated,
> simple and reproducible I do not consider this a very far departure
> from the original source. IMO you don't modify the source at all you
> just strip binaries which are not part of the source anyway. (And you
> keep source package downloads considerable smaller for those who have
> a 250k-emerging-market-country internet access as I do ;-) ).

That is absolutely correct. My reason for keeping the source intact is
to allow the user to verify the correctness of the original source via
easily comparing it to the upstream package. Both reasons are IMO
equally valid, and both are allowed by the ftpmasters.

--
* Sufficiently advanced magic is indistinguishable from technology (T.P) *
* PGP public key available @ http://www.iki.fi/killer *


--
To UNSUBSCRIBE, email to debian-java-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org