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

Re: RFS: jmapviewer/1.02+dfsg1-1 [ITP]



Hi Felix,

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.

> > 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.  At least I formyself am using it in any
of my java packages quite successfully.  It is fine for me if you
have your reasons to avoid it but for the sake of interest I would
like to hear your reasons.

Kind regards

        Andreas.
 

-- 
http://fam-tille.de


Reply to: