[Debian-med-packaging] Trouble updating velvet Git repository

[Andreas Tille]

Hi Charles,

On Fri, Aug 02, 2013 at 09:07:04AM +0900, Charles Plessy wrote:
> Le Thu, Aug 01, 2013 at 02:44:47PM +0200, Andreas Tille a écrit :
> > 
> > I intended to work on velvet Git repository.  I was able to commit some
> > enhancements regarding new uscan[1] so git-orig-source is using it if
> > available otherwise it proceeds as usual.  Once I tried to inject the
> > newly downloaded tarball I get:
> 
> Hi Andreas,
> 
> when I prepared the Git repository for velvet, my aim was to track directly the
> upstream repository without the use of git-import-orig.  This is not the
> standard in our team, but this is something that I would like to do for the
> packages I maintain.

???

If I'm not misleaded you have ironed out the way we use gbp in the first
place.  If you have gathered some new knowledge and found out that the
original approach might have some drawbacks to other ways it might be
interesting to learn this and at least describe the alternatives in
policy.  I'd personally follow what looks the most simple way to do
things and I feel incompetent to have an opinion on how to use gbp most
efficiently.

> Unfortunately, starting from this year, I have much less
> time for packaging, so I can not keep the leadership on packages such as
> velvet.
> 
> One possible solution is to switch back using the Subversion repository, which
> is still in place.  Another is to create a Git repository from scratch.
> Lastly, you can also try to follow the upstream repository directly.  In that
> case, just pull the upstream branch from the master on GitHub, and resolve the
> conflicts if any by committing to our master branch.  No need for
> debian/patches.  Be careful to not use the source format 3.0 (quilt), which
> will interfere.

Hmmm, I think to get out something quite quickly it seems to me that the
"keep SVN approach" fits best.  I'm willing to learn new things but for the
moment the stack of packages is quite large and I'd like to work it down a
bit.  New things can be done if things are settled a bit.  I guess it is
OK for you if I remove the Git repository from git.d.o to avoid confusion?

> By the way, note that appending "+dfsg" to the version number is misleading.
> Velvet is 100 % Free.  However, it contains a convenience copy of the Zlib, and
> in order to keep it in the source package, one would need to copy all its
> copyright notices to debian/copyright, while the licenses do not require us to
> do so.

I'm aware of this.  I was more leaded by the fact that it might make
sense to use some unique appendix for packaged upstream sources and
+dfsg is quite commonly used (for sure for a reason) and the enhanced
uscan is just appending this.  I cna not see any real harm by using this
appendix also for originally dfsg free software.  You might like to
translate "this" dfsg by "Debian Featured So Good" or something like
this.

> My despair with this idiotic policy is probably what made me drop the
> work on velvet in 2012.  Sorry for this.

No problem.

> Altogether, I think that packages requiring such changes in their source are
> better to be maintained in the Subversion way.

So finally we agree. :-)

Thanks for your insight

      Andreas. 

-- 
http://fam-tille.de