Bug#620829: [new checks] implements parts of the java policy
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
On 2011-04-04 16:04, Vincent Fourmond wrote:
> Package: lintian
> Version: 2.5.0~rc1
> Severity: wishlist
> Tags: patch
>
> Hello,
>
Hi Vincent
> Currently lintian does not cover at all the java packaging policy,
> and that's probably one of the reasons why it is not very well
> respected (especially since there are some quite devious tricks
> there).
>
Thanks for your interest in improving the coverage of the Java policy.
It was also my original intention when I joined Lintian (I admit being a
bit carried away :P ).
Have you also had a look at http://wiki.debian.org/Java/QATools ? It is
possibly a bit outdated, but I think most of the suggestions are still
worth considering.
Also feel free to add the things you are working on; hopefully that
will avoid duplicated work. :)
> I have started an implementation of that in a clone of the git
> repository. I have attached a patch containing some of my work. Please
> note that this patch addresses #575447 but also a lot more.
>
What is classpath-contains-relative-path about? I have never heard any
security issues with related to relative classpaths (nor do I recall any
request to have the Java policy amended to take care of this). Could
you provide a reference to this issue?
Then there is the /usr/share/ part, which I am not too sure about
anymore. I originally thought that swt was the only one of its kind but
eclipse turned out to contain a lot of them actually. Of course this is
(in itself) no excuse for the rest of the arch independent jars to be
installed outside /usr/share. Maybe we can start with a lower
severity/certainty and then bump it to an error later.
Also you/we need to set up the java policy in
data/output/manual-references so we can use java 2.2 and java 2.3 in
checks/*.desc ref fields.
> I plan to go on working on that, if that's fine by you. Anyway,
> there are a lot of things that still need to be implemented. What is
> the workflow of the lintian team ? Shall I send you regularly batches
> of git format-patch ? (which I haven't done this time). How can I
> actually join the lintian team ?
>
I am not too sure of the general work flow, but feel free to send
patches e.g. via bugs if you have more tags/changes. Personally I would
prefer if you used git format-patch (easier for me).
I believe you can test it by using:
LINTIAN_ROOT='.' frontend/lintian-info -t <tag>
Assuming you did not know it, you can also use frontend/lintian in a
similar fashion to test your changes without having to build and install
lintian.
> Cheers,
>
> Vincent
>
> -- System Information:
Comments on the patch itself (aside from the questions about some of the
tags above):
Why the "use" of common_data and File::Basename? The check does not
appear to use either.
Why is the check "binary only" but the collection "binary + udeb"? I
doubt we have any udebs with jar files, so I think it is safe to make
both "binary only".
I believe that the java_info sub in Lintian::Collect::Binary needs a
# sub java_info Needs-Info java-info
line. There is an automated test to check for this stuff. Secondly it
needs POD documentation (see the bottom of the file).
@jarwrapper_or_equivalent could be turned into a string - if we get
alternatives we can use "jarwrapper | alternative". This is what we do
with (e.g.) $PYTHON_DEV in checks/fields.
Please add automated tests for the tags (see t/tests/README or existing
tests for more information). We are trying to keep t/COVERAGE as empty
as possible. :) I have no strong preference to whether the tests should
be in the same patch or not, so do what is easiest for you.
You can test individual tests by using:
debian/rules runtests onlyrun=<name-of-test>
- OR -
debian/rules check-tag tag=<name-of-tag>
Note the name of the test is the one listed in its desc file - if you
copy/paste a desc file and forget to update the name in it, you may see
some "funny" results.
Please make sure that the test-scripts still pass with your patch. You
can check this by running:
debian/rules runtests
and wait for:
"""
t/scripts/<something> [...] ok
All tests successful.
Files=37, Tests=9640, [...]
Result: PASS
"""
You also ought to run the entire tests to ensure your new tags are not
triggered in the test suite (causing other tests to fail), but I have
feeling we do not have a lot of jar files in our test suite (yet). :)
Finally, we are planning to release 2.5.0~rc2 soon and I am hoping to
merge a branch shortly after the release. *If* this branch is merged
your collection will need to depend on two new collections (index and
fields), since these will provide the "index" file and the "fields/"
directory (respectively) in that branch.
If you check for the index file instead of fields/package, then you
can avoid the fields dep as far as I can see.
The check will also need a Needs-Info on fields ($info->relation).
~Niels
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iQIcBAEBCAAGBQJNmzesAAoJEAVLu599gGRCVhoQAJGTGUt3KrQF0uk6Chs7cSCB
cwf3Rm5JggBmq+MBKJqrZiaTGqashSOFjTCYFgYD26C+jCv7n9AHlGPwpee8Ugja
EkzRZ59w6OhhT9/ny973pDXR5oqcwSy5RxozR1e2dqApy8R6Lt5qeT7TxaP2Hnj/
3xAuiiQAX0/flYHu218MI7vKd69FvpCUBueHllv9a+UObQPHlVoEJUKceRhPMiDs
VK9YSnAs8qB3WzqULt4J+LDC5eKMN4A2eLrgeLlGGhi4AEeC2Id2N3/uRP8PVgIl
k5Fx1b8MFJpibafOeS1nYlKjdn8/IZqudyxG/uEDtFiF5CMl86kDrSLI0pyGyqyU
9j63hOm2prR176DAO96pzXq6qIl1ugpNjgswjcrOD/qT0SyUm7qO1MNdegMc5Tqm
uFpvCpMLJ17hM93NM/YKKrRA13FzVYgCgbBgdrkJpy9PZX8dapV5gG022wVGhbc4
14BKiooh8qWGomU9csDZa7TU7/u+8H6MgBj4AwwwmfkdzxQFEtksXz6vDzh4AkUO
vv+V8uRhJYHZXxt9/yV91Hk2fJfI5xtcA+SjyfBB8A/u/BXUflNX6LRiTrFWD66s
gFFM66lC/GcuZGkhihR6zp5UTn9tbtGXL+Vte6FQhS7Qv6Yiu6m3GAZ8Nry+AcDc
hD4oynIS0O4lbfM8MD3T
=UMxP
-----END PGP SIGNATURE-----
Reply to: