[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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


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.

    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: