[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Workflow with debian/ in VCS

Ben Finney <ben+debian@benfinney.id.au> writes:
> Nikolaus Rath <Nikolaus@rath.org> writes:
>> Hmm, but you snipped away step #4: making changes to the debian/*
>> tree. How do I incorporate that into the workflow?
> You just, um, do it? I don't know why that would be different.

Well, you said:

>>> 3. Copy debian/ from repo into extracted directory
>>> 5. Run debuild
>> These two steps are what ‘${VCS}-buildpackage’ does. You don't have to
>> have the build artefacts cluttering up your working tree; it does its
>> work elsewhere.

So if I'm using -buildpackage to do these two steps at once, how can I
still do the intermediate step? Press Ctrl-Z at exactly the right time?

>> >> 6. Copy debian back into repo
>> >
>> Ben Finney <ben+debian@benfinney.id.au> writes:
>> > [copying the ‘debian/’ directory in and out is] obviated by having
>> > the repositories separate, and automatically combined when needed.
>> I don't understand. I can only modify the debian tree when the upstream
>> sources are present in the same directory (otherwise I can't update
>> patches)
> Sure you can update the patches. You make the patches from the VCS
> repository for the upstream source, just as you'd expect. The only
> difference is where you place the resulting patch.
> In my case:
>     $ pwd
>     foo.debian/
>     $ ( cd ~/Projects/foo/mychanges/ && bzr diff -p 'old/:new/' ../trunk/ ) > debian/patches/03.mychanges.patch
> Perhaps I'm not understanding you.

That would certainly work, but I was thinking about the more automated
patch workflow with dquilt, which needs, AFAIU, to be run in the
directory with upstream sources and will put the patches into ./debian/.
So afterwards I will have to copy debian/ into the VCS.



 »Time flies like an arrow, fruit flies like a Banana.«

  PGP fingerprint: 5B93 61F8 4EA2 E279 ABF6  02CF A9AD B7F8 AE4E 425C

Reply to: