Bug#620829: [new checks] implements parts of the java policy
On 05/04/11 17:39, Niels Thykier wrote:
> 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. :)
OK, thanks for the pointer.
>> 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?
Hmmm... Maybe I got a bit carried away, as the JVM seems to pick
relative JAR paths with respect to the directory the original JAR is in.
However, a quick look into the jars I have here show that many
incorporate classpaths that are suitable in the build directory, but not
on a debian system. Often, this is like lib/something.jar and the like.
I should restrict the scope of the check to relative paths having a
subdirectory and turn the "relative path" (regardless of subdir) into a
pedantic flag, suggesting that probably the maintainer didn't pay
attention to the classpath at all ?
> 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.
Of course, but as of now, it is a policy violation. We can wait until
turning that into an error, though.
On that side, many libraries I'm aware of do not respect the policy of
lib<pkg>-java and /usr/share/pkg(-something)?.jar. Should this be
enforced too ? Maybe as a warning in the first place ?
> 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.
OK, I'll do that.
>> 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).
Then I shall send you a tarball with the resulting directory.
> 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.
or:
alias my-lintian="$HOME/Prog/lintian/frontend/lintian --root
$HOME/Prog/lintian/"
Thanks, I found that one quick enough ;-)...
>> -- 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.
Hmmmm... Just copy/paste and a lack of wish for trimming ;-)...
> 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".
OK
> I believe that the java_info sub in Lintian::Collect::Binary needs a
> # sub java_info Needs-Info java-info
OK.
> line. There is an automated test to check for this stuff. Secondly it
> needs POD documentation (see the bottom of the file).
OK.
> @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.
OK
> 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
> """
Thanks, looks like I'll have to dig a little further, then ;-)...
> 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).
Well, thanks a lot. I'll work on all that later on tonight, hoping to
send a format-patch early enough for the rc2 release.
Cheers,
Vincent
--
Vincent Fourmond, Debian Developer
http://vince-debian.blogspot.com/
If there was anything that depressed him more than his own cynicism, it
was that quite often, it still wasn't as cynical as real life.
-- Terry Pratchet, Guards, guards !
Vincent, listening to Human Behaviour (Björk)
Reply to: