Andreas Tille <[email protected]> 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 [email protected] 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 -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: http://lists.debian.org/[email protected]
