Re: ncbi-tools6 does not simply build via gbp due to changed files
Hi Aaron,
On Sun, Mar 25, 2018 at 09:48:31PM -0400, Aaron M. Ucko wrote:
> > since Liubov Chuprikova added autopkgtest to ncbi-tools6 I tried to
> > build the package but failed. The repository contains upstream files
> > that are different from the upstream tarball and it is not clear to me
> > how this package should be build at all with this setup.
>
> This setup historically worked fine, just didn't accommodate added (or
> changed) *binary* files (as introduced by this test).
Yes, the binary data file made the issue obvious.
> > Moreover it seems to be the only package of Debian Med team that is
> > not using source/format 3.0 (quilt) which should be used according to
> > our policy[1] unless a different format brings a specific advantage.
>
> I must have missed that detail. My personal preference has long been to
> treat Debian source trees as ordinary branches of the corresponding
> upstream codebases, since I find this arrangement more natural and in
> many respects more straightforward to work with than a patch system,
> even with the help of quilt.
I admit that there is probably no right or wrong in the choice of a
workflow but if it comes to team maintenance commented patches are more
obvious for your team mates.
> I'm pushing changes that formally switch to 3.0 (quilt) and inform
> dpkg-source that it has a (specific) binary file to accommodate. I've
> declared single-debian-patch mode for now, though, since I don't have
> time to split out individual patches at the moment.
That's fine. Some patches look as if you have forwarded these upstream
and we can create more sensible patches with next upstream version.
> In the long term,
> how do you feel about gbp-pq(1) as a compromise between our preferred
> approaches?
I admit I have never dealt with this. I think I can live with it if gbp
would work out of the box. If there are some specific hints needed
please frop these in debian/README.source.
> BTW, I see that the repository has moved to Salsa (thanks!)
May be we should flag messages like this[1] more prominently with
[ANNOUNCE] or something like this to make everybody aware of important
changes.
> Are you planning to update the Vcs-* fields accordingly?
With the advent of the lintian warning I started a thread on
debian-devel list. It seems[2] there will be another round of changing
VCS fields and there will be no way to safe the anonscm addresses (which
were *invented* to *not* to be changed). As usual the only way to work
around is probably to setup a DNS redirect yourself if nobody else is
doing it for you - but I do not try to fight wind mills. So my personal
policy is to wait until a simple
cme fix dpkg-control
(which I'm doing on every package upgrade anyway) will do the change
for me and than do things per package upgrade. I'm not motivated at
all to go on update the close to 1000 packages I ever uploaded and will
be quite relaxed about this warning. What I will do once the Alioth
redirector will stop working is to add some regexp to the web sentinel
to make sure the URLs will be correct there.
In short: If you want to change Vcs URLs manually now you do not need
to do it later.
Kind regards
Andreas.
[1] https://lists.debian.org/debian-med/2018/02/msg00016.html
[2] https://lists.debian.org/debian-devel/2018/03/msg00419.html
--
http://fam-tille.de
Reply to: