>>>>> "Sean" == Sean Whitton <spwhit...@spwhitton.name> writes:
Sean> Hello,
Sean> On Mon, Aug 14 2017, Ian Jackson wrote:
>> There are three situations I think:
>>
>> 1. fetch. There is a pristine-tar branch available somewhere.
>> You want to avoid downloading the .orig, and instead use
>> origtargz from the pristine-tar branch.
Sean> This is what Sam wants.
Not really.
What I want is I have a clone of a maintainer branch of a dgit
repository. It's got a pristine-tar branch. For whatever reason I don't
have the tarball checked out.
I guess I might end up doing a dgit pull before my push, I haven't used
dgit often enough to know whether I am going to want that regularly or
not.
What I know I want today is a way to generate the tarball so that dgit
build-source or dgi- sbuild will succeed.
origtargz works great for this: I didn't know of its existence.
>> 2. push. You have a local pristine-tar branch and are making a
>> new upstream version. You do not have the .orig as a file. You
>> want to synthesize the .orig for the upload.
Sean> gbp already has very good support for this. I don't think it
Sean> would be wise to add anything to dgit.
This is very close to my use case.
I'm happy to use gbp's support for this so long as I can use sbuild as a
builder alongside gbp.
>> 3. origless workflow. You have a pristine-tar branch and want to
>> avoid having origs hanging around.
Sean> I don't know of anyone who does this -- people don't usually
Sean> think of pristine-tar as a tool for this purpose.
Well, I consider orig.tar.gzs and dscs to be cached items: it's OK to
delete them at any time.
So, I tend te delete them regularly assuming that they can be
regenerated.
But I don't mind needing to regenerate them.
Running origtargz before dgit sbuild is probably fine for me, although
I'll note that it was nice that gbp buildpackage did this for me.
