Re: RFS: jmapviewer/1.02+dfsg1-1 [ITP]
Andreas Tille <andreas@an3as.eu> writes:
> Hi Felix,
hello Andreas,
> On Mon, Oct 21, 2013 at 09:21:47PM +0200, Felix Natter wrote:
>> >> Am I missing something?
>> >
>> > Yes. Assume somebody else does the following:
>> >
>> > $ apt-get source jmapviewer
>> > $ cd <maindir>
>> > $ uscan --verbose
>> >
>> > ---> results in a new version tarball *including* the files that
>> > needs to be removed.
>>
>> Still it seems a bit strange to do that because you've got the filtered
>> source at your fingertips ;-)
>
> When looking at the world through git-glases, yes. If you are git
> ignorant it is different. As long as Git is not mandatory in policy
> we should follow the rules written down there.
>
>> > Uscan is orthogonal to the used version control system. You should
>> > either provide a get-orig-source target doing the removal of the file or
>> > take the new uscan.
>>
>> How can I use the new uscan?
>>
>> I guess it's here:
>> http://anonscm.debian.org/gitweb/?p=users/tille/devscripts.git;a=tree;f=scripts;h=ab0fe34c78f07dc30ed48536b7314b0b0fe24ff1;hb=HEAD
>>
>> but how would I make every user of the package use the new uscan?
>
> Yes.
>
>> Is the
>> "Files-Excluded: ..." hack already included in the current uscan?
>
> It is not yet, but the devscripts maintainer was positive modulo needed
> psare time about it.
>
>> Sorry
>> for the stupid question, but I couldn't find the answer here:
>> https://wiki.debian.org/UscanEnhancements
>
> There is a small hint at
>
> https://wiki.debian.org/UscanEnhancements#Acceptance_of_the_patch
>
> if you read the full comment.
>
>> Or is it that $USER only gets the "Files-Excluded:" functionality if
>> he/she has a new uscan, and we ignore the rest?
>
> That's currently the case. My suggestion to use this was some
> compromise to reduce your work somewhere inbetween no get-orig-source
> at all (as currently) and a get-orig-source target working right now
> for everybody, which looks for instance like this:
>
> http://anonscm.debian.org/viewvc/debian-med/trunk/packages/python-biom-format/trunk/debian/get-orig-source?view=markup
>
> This script realises the (manually installed) new uscan and if it does
> not exist it does some work to create the real source tarball. My
> suggestion would have been a one-liner in debian/copyright which is
> quite less work for you and should work in the future stable release
> Jessy ... which is at the same time the first stable release with
> jmapviewer. This might be somehow consistent while creating the least
> work on your side.
Ok, I have added support for Files-Excluded:, and it works with the latest
master uscan from your repository. BTW: Files-Excluded: is nice because it's
easy (declarative) and because it's clearly documented in the package
which files have been removed and it's automatic, so cheers for the
effort :-)
>> > My git-buildpackage is configured to call pbuilder - may be that's not
>> > the case on your side?
>>
>> Do you really want to add the overhead of pbuilder on every single
>> build? Or do you use dpkg-buildpackage instead of gbp buildpackage for
>> intermediate builds? Just curious :-)
>
> In *most* cases I'm using pbuilder (actually cowbuilder which is
> faster). I use only debuild in very rare cases if I have strong
> reasons. In any case I use pdebuild when I upload a package und thus
> the build simply needs to work with pbuilder.
>
>> > So I think the last remaining issue is the question what Java-Depends to
>> > use. Please try to contact debian-java@lists.debian.org about this.
>>
>> I received a reply and I think I've got it worked out:
>>
>> jmapviewer declares:
>>
>> Depends:
>> openjdk-7-jre,
>> ${misc:Depends}
>>
>> - ${misc:Depends} is used by debhelper in general, and it's required by
>> debhelper, see:
>> http://lintian.debian.org/tags/debhelper-but-no-misc-depends.html
>>
>> - ${java:Depends} is only used by the 'javahelper' java build system (a
>> simple build system that is to be used if there is no ant script or
>> similar) --> for example 'libjsyntaxpane-java' depends on
>> ${misc:Depends} and ${java:Depends}.
>> => jmapviewer uses an dh/ant build system, so this is not
>> necessary/applicable
>>
>> => should be correct as is.
>
> Ahh, that's interesting. However, why aren't you actually not using
> javahelper? I admit I did not checked your Build-Depends / dh about
> this because I (stupidly) assumed you would use javahelper as it seems
> to be advisable in any case.
No, to my understanding javahelper is useful only when there is no
upstream build system (like ant or maven). From
/usr/share/doc/javahelper/tutorial.txt.gz:
--------------------------------
jh_build
--------
Many Java programs and libraries are distributed without sane build
systems. `jh_build` provides a simple interface for building Java
source code into Jars, including setting the appropriate entries in
the manifest.
In almost all cases all that needs to be done to call `jh_build` is to
set `JAVA_HOME` and `CLASSPATH` and then call `jh_build` with the name of
the jar and the directory containing the source.
JAVA_HOME=/usr/lib/jvm/default-java
CLASSPATH=/usr/share/java/esd.jar:/usr/share/java/jsch.jar
jh_build weirdx.jar src
This command will compile all the Java files under src, set the
classpath in the manifest and build it all into weirdx.jar.
--------------------------------
=> since jmapviewer has an upstream ant build system, I am using that
with debhelper. dh automatically detects that there is an ant build
system (build.xml) and does the right thing.
> At least I formyself am using it in any of my java packages quite
> successfully.
I guess you are maintaining packages without a build system then (or you
are ignoring the build system) :-)
Thanks for Reviewing and Best Regards!
--
Felix Natter
Reply to: