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

Re: ITP: HTSeq



Hi again,

(sorry for the full quote below but my mail below did not reached the
list for whatever reason ...)

I had another thing to consider:  The soure tarball of python-htseq
contains two scripts in scripts/ directory.  If I'm not totally
misleaded these are the user interface to the Python code end should be
installed to /usr/bin ... or at least to /usr/share/doc/<pkg>/examples.
In the first case please use help2man to create some simple manpage
(we have examples for instance in packaging of last-align).

Moreover if you consider these scripts as the main interface for the
package which makes it kind of a user application rather than a Python
module there is no real point in naming the package python-htseq.
Finally it does not matter for the user in what language some software
is written in and thus a simpla htseq would perfectly do.

Kind regards

      Andreas.

PS: Diane, could you please confirm whether you got the mail below.
    I'm wondering why it did not appeared on the list even after
    close to two hours.

On Fri, Jul 26, 2013 at 09:01:05AM +0200, Andreas Tille wrote:
> Hi Diane,
> 
> On Thu, Jul 25, 2013 at 03:23:49PM -0700, Diane Trout wrote:
> > I tried to help debian-med with samtools a while ago. So I already have an 
> > alioth account and even already have a debian-med membership:
> > 
> > diane-guest@wagner:/git/debian-med$ groups
> > diane-guest debian-med pkg-kde scm_debian-med scm_pkg-kde
> 
> Ahhh, please excuse my bad memory specifically before I felt asleep
> yesterday evening. ;-)  Yes, I remember now and I confirm again that I'm
> happy about your contribution.
>  
> > And I've been contributing some to the KDE & Python teams over IRC.
> 
> Great you are in connection with Python teams - this will help for your
> current target.
> 
> > Looking at your repository guide, it looks like you prefer git-buildpackage 
> > style packages?
> 
> The first git-addicts started this way and others followed.  It seems
> this approach makes somehow sense even if I'm personally not fully
> convinced that it makes sense for all packages - specifically the very
> large upstream source ones.  So in principle I do see room for
> exceptions in the future to not store the full source but as far as I
> know git-buildpackage can also deal with this repository layout (I never
> tried personally).
> 
> > I had one problem where upstream includes the .egg-info directory in their 
> > source release, and I had trouble resetting the build sufficiently for gbp to 
> > work because the *.egg-info/SOURCES.txt kept changing. 
> 
> I would suggest to ask on debian-python mailing list (or IRC if this is
> your prefered way of communication) because I expect them to have more
> experience with this kind of things.
> 
> > Do you have any suggestions for getting around that? (Is there a way to tell 
> > git-import-orig to ignore the egg-info directory for instance?)
> 
> There might be another way to handle this.  You could simply repack the
> upstream source in a get-orig-source target.  The most simple way to do
> this kind of things is using my proposed way for uscan enhancements[1]
> which for example is used in the get-orig-source target of the
> gnumed-client package (see at bottom).
> 
>    http://anonscm.debian.org/viewvc/debian-med/trunk/packages/gnumed-client/trunk/debian/rules?view=markup
> 
> which strips all files mentioned under Files-Excluded inside
> 
>    http://anonscm.debian.org/viewvc/debian-med/trunk/packages/gnumed-client/trunk/debian/copyright?view=markup
> 
> To demonstrate what I mean I attached a diff that adds a get-orig-source
> target which removes the directory in question from upstream tarball.
> The version number gets automatically some '+dfsg' attached (which in
> this case is not really a dfsg licensing change - it simply adds a
> string to flag that it is not the original upstream source) and thus the
> watch file needs a change as well.
> 
> On my system I have a copy of scripts/uscan.pl (see remark in d/rules)
> in ~/bin/uscan - so this works perfectly.  I hope it will be incorporated
> in official devscripts soon.
> 
> But please, if you want to know how Python experts are dealing with
> egg-info dirs, ask on debian-python.
> 
> 
> For the rest of the packaging you did it is fine except some minor
> details.  Please add a doc-base file for the html documentation that is
> shipped inside the doc package.
> 
> 
> To come to the final nitpicking I would prefer the original upstream
> short description provided at the weg page as package short description:
> 
>   Description: analysing high-throughput sequencing data
> 
> In any case please drop the "package for" in your proposed description.
> The rationale is that short package descriptions should read like:
> 
>   Package <name> is / can be used for <short description>
> 
> So the term <package> id redundant inside the short description.
> 
> 
> I also found some http_proxy setting in your debian/rules file.  I do
> not think that this does harm in any way - but it comes to mind that you
> should never relay on beeing online when building a package.  So in
> principle you should never relay on any http_proxy settings in your
> rules files.  If the packaging depends on it something is wrong.  (I
> builded in pbuilder successfully and the proxy you mentioned does not
> exist - so the packaging in principle is OK.)
> 
> 
> If it happens that you did some packaging of other interesting software
> we are keen to learn about these.
> 
> Kind regards and thanks again for your work on this
> 
>       Andreas.
> 
> [1] https://wiki.debian.org/UscanEnhancements
> 
> -- 
> http://fam-tille.de

> diff -ubrN debian.orig/copyright debian/copyright
> --- debian.orig/copyright	2013-07-25 21:59:23.000000000 +0200
> +++ debian/copyright	2013-07-26 08:40:54.000000000 +0200
> @@ -2,6 +2,8 @@
>  Upstream-Name: HTSeq
>  Upstream-Contact: Simon Anders
>  Source: https://pypi.python.org/pypi/HTSeq/
> +Files-Excluded:
> + HTSeq.egg-info
>  License: GPL-3+
>   This program is free software: you can redistribute it and/or modify
>   it under the terms of the GNU General Public License as published by
> diff -ubrN debian.orig/rules debian/rules
> --- debian.orig/rules	2013-07-25 21:59:23.000000000 +0200
> +++ debian/rules	2013-07-26 08:44:07.218609829 +0200
> @@ -32,5 +32,13 @@
>  	rm -rf *.egg-info
>  	dh_clean
>  
> +# Remark: The following uscan command requires devscripts > 2.12.4 which is not
> +#         yet released at the time of this package release.  The code can be obtained
> +#         via
> +#   git clone git://tille@git.debian.org/git/users/tille/devscripts.git
> +#         and then use scripts/uscan.pl
> +get-orig-source:
> +	uscan --verbose --force-download --repack-compression xz
> +
>  .PHONY: clean
>  
> diff -ubrN debian.orig/watch debian/watch
> --- debian.orig/watch	2013-07-25 21:59:23.000000000 +0200
> +++ debian/watch	2013-07-26 08:43:12.966608175 +0200
> @@ -1,4 +1,4 @@
>  version=3
> -opts=uversionmangle=s/p/./ \
> +opts=uversionmangle=s/p/./,dversionmangle=s/\+dfsg[0-9]*// \
>  https://pypi.python.org/packages/source/H/HTSeq/HTSeq-([0-9.p]*).tar.gz
>  #https://pypi.python.org/packages/source/H/HTSeq/HTSeq-0.5.4p3.tar.gz


-- 
http://fam-tille.de


Reply to: