Re: debuild/dpkg-buildpackage behaves not as expected

[Goswin von Brederlow <goswin-v-b@web.de>]

debian-devel@liska.ath.cx (Olе Streicher) writes:

> Goswin von Brederlow <goswin-v-b@web.de> writes:
>>>> If you need to change a file then that means that file isn't source
>>>> anymore but generated. Try switching to out-of-tree builds if you have
>>>> something like that.
>>>
>>> What is the advantage of that? From the Debian policy, I don't see a
>>> need why sources should kept untouched during the build process.
>>
>> Less surprises by someone unfamiliar with the source. For example:
>>
>> - you (as in some porter, not the maintainer) build the source to
>>   reproduce a FTBS 
>> - it fails as expected
>> - you edit the broken file
>> - you build again and it works
>> - you call clean so you can make a patch
>> - clean restores the original source file destroying hours of your
>>   work
>
> If I would be unfamilar with the source, I would just not expect that
> the package behaves as I would do it myself. Instead, I would be ready
> for the case that it does tricky, undocumented things with the source --
> and create the debian patch before I am going to build the package.
>
> Why should a porter expect more from a package than the requirements
> specified in the policy?

Because I'm an optimist. When I work on a new source package I naively
assume that the source is nice and does no evil, ugly, hackish things.
Obviously that leaves me disapointed when it does.

But all of that doesn't mean a source isn't better if it doesn't do
evil, ugly, hackish things. Policy might not require it but common sense
encourages it.

>>> It is just the better design: the package was built with a patched
>>> source, so only the patched version knows for sure how to clean it up. 
>
>> Note that it only calls clean with unpatched sources if you
>> specifically unpatched your source before calling it.
>
> If you insist so much on this standard: why does debuild (or
> dpkg-buildpackage) undo the patches if they were not applied before? In
> this case, it would be up to the (rare) people to unpatch if they need
> this. One could even provide a debuild/dpkg-buildpackage option for that
> (like --unpatch-after-build or so), or do it in a hook.

There already is the uapply-patches option. But then the patch is always
unpatched after build instead of returning to the state prior to build.

>> So I think having the clean target make sure patches are applied if
>> needed is the better design.
>
> .... which again does not behave as expected: if "clean" depends on
> "patch", then after "debuild clean" the packages is in the "patched"
> state even if it was unpatched before. 

Yes, if you just depend on patch then that is the result.

clean:
        $(PATCH)
        clean up everything
        $(UNDO_PATCH)

where PATCH is a makro that records the current patch state (like dpkg
itself does) and UNDO_PATCH a makro to return the patch state to what
was saved. I haven't tried this but you can probably make those makros
use exactly the state file and format dpkg uses for abest results.

> I think the best way would be that debuild/dpkg-buildpackage would not
> automatically unapply the patches (so it would leave the source in the

It doesn't automatically unapply the patches. It only restores the state
you had before the dpkg-buildpackage was called.

> way that is described as "standard" for Debian), with a special option

Which means that if you start with the "standard" of patches applied
then they will remain applied. But if you manually deviate from the
"standard" then it will preserve that deviation too.

> or hook that does this for those who really need it (and know what they
> are doing).

Which would mean that you would have to unapply patches every time you
try to build while working on a patch. With the current behaviour I can
do

quilt push foo.patch   (foo.patch being somewhere in the middle)
edit file
quilt refresh
debuild
edit file
quilt refresh
debuild
edit file
quilt refresh
debuild

>> I was describing the case of having changes commited to the RCS and
>> generating debian/patches/* automatically (or a single debian-changes
>> patch).
>
> A single debian-changes patch is evil -- even Lintian complains there. 
> Handling a single debian-changes patch is something I would explicitely
> *not* take as a valid use case.
>
> Is there a way to automatically handle a bunch of individual patches
> trough an RCS?

git-pkg has something for that for example.

> Best regards
>
> Ole

MfG
        Goswin