[Debian-med-packaging] samtools i386-buildable

[Andreas Tille]

Hi Charles,

On Wed, Sep 16, 2015 at 09:24:19PM +0900, Charles Plessy wrote:
> I am not completely surprised to read your email :)

:-)
 
> Le Wed, Sep 16, 2015 at 11:56:32AM +0200, Andreas Tille a écrit :
> > 
> > If upstream decides to rewrite a script xyz.pl in Python and will name
> > it to xyz.py users scripts will be broken as well.
> 
> In 10 years I never saw this happen.

IMHO that's no valid argument.  Sometimes things happen that did not
happened for 20 years.  (I do not doubt that I trust your better insight
than mine that the scenario I imagined is very unlikely.)
 
> > To save our users
> > from this section 10.4 of the Debian policy was written.  You can not
> > save users from all bad things that might happen and thus I try to
> > follow sensible arguments.  These were frequently given and since the
> > discussion comes up frequently I now assembled a section on the Upstream
> > Guide wiki page:
> > 
> >    https://wiki.debian.org/UpstreamGuide#Language_extensions_in_scripts
> 
> Thanks, this is where it belongs.  But when upstreams beg to disagree with our
> dogma, I think that we should not escalate by making Debian incompatible with
> other platforms.

Does upstream really *disagree* with us in a way that we brought this
problem up before and got a well thought answer to this or did we never
asked upstream or did not got any answer to our request.  (I'm to
lazy to seak the archive.)
 
> > BTW, since the creation of /usr/lib/debian-med/bin we could consider to
> > keep the scripts including the extension there.  I'm not convinced that
> > this a good idea - just mentioning it as a possible compromise.
> 
> I would rather keep this directory for pure namespace conflicts.
> 
> By the way, I just read about https://packages.debian.org/sid/environment-modules
> on Biostars.  Maybe it is something to investigate...

I confirm that modules came up in some past discussion on Debian Med
sprints (?) and also recently in Debian Science BoF.  I'd be happy if
somebody would investigate some time into this and makes some proposal
how *exactly* we could use it for our purpose.
 
> > IMHO using Git should be no excuse to break good packaging practice to
> > be able building packages twice in a row.
> 
> I would say the reverse: Git provides us great tools to reset a working
> directory, and it is a waste to not use them.  10 years ago, it could have been
> reasonable to say things like "I am a darcs|bzr|mercurial|whatever user, Git
> has no future, I will not spend my time learning it", but as of today anybody
> who want to do serious Debian development needs to know Git.
> 
> Our packages are writable for all Debian developers; in return I think that we
> should be a bit more firm about asking people to make their changes in the Git
> repositories, and avoid working in the raw source packages, which are merely a
> vehicule to send the source to the autobuilders.  

I beg to differ here (not about the role of Git since there is no doubt
about its role).  There are people who working on QA tools and amongst
these are people who check whether a package builds twice in a row.  And
a clean target is a clean target and we should strive to get this
working properly.  I admit I do not always reach this goal in all
packages I touched myself.  However, there is a valid point in the
request to build twice in a row and it is wrong to force a certain tool
upon somebody (how nifty and wide spread it might be).

Kind regards

      Andreas.

-- 
http://fam-tille.de