Re: tag2upload (git-debpush) service architecture - draft
On 31/07/2019 17:08, Ian Jackson wrote:
.dsc generation is complicated, slow, and inconvenient.
In what circumstances is it slow enough to matter?
My measurements, in a sid chroot:
source .orig .debian origcreate dpkg-b.
size size time time
dgit(native) 4M 0.3sec 1.4sec
beignet 1M <0.1M 0.5sec 1.7sec
theano 13M <0.1M 1.4sec 1.8sec
libgpuarray 0.3M <0.1M 1.6sec 2.1sec
statsmodels 10M 0.2M 1.7sec 3.3sec
pandas 8M 4M 1.6sec 31.4sec
origcreate = create the *.orig.tar.* from the git repo (time gbp
buildpackage --git-builder=/bin/true --git-cleaner=/bin/true)
dpkg-b. = build the source package (.debian.tar.* + .dsc + .changes)
from that .orig and the repo (time dpkg-buildpackage -S -d -nc -us -uc)
The bad case (pandas) is a non-native package with a big /debian, which
is rare (~30 this big in sid), and even it's quick compared to
building+testing the binaries.
-----------
Do "complicated and inconvenient" mean "harder to remember than 'git
debpush'" (which could equally well be fixed by a local-only script),
the confusing errors mentioned below, or something else?
On 31/07/2019 20:21, Sean Whitton wrote:
Just fyi, it is indeed as simple as [dgit push-source && git push --all --follow-tags]. However, when
there are errors, it is quite a bit harder to understand what's going on
than it is with git-debpush/tag2upload, basically because there are
.dscs involved.
If git debpush / tag2upload have better error handling, could that code
be used to improve dgit push-source?
(I don't think we'd want to make git-debpush a wrapper for that because
it is not a pure git command, so shouldn't be in the git-* namespace.)
I'm fine with calling it something else (though I find it weird that 'do
X' isn't OK but 'ask a server to do X' is): suggestions?
Reply to: