Re: debuild/dpkg-buildpackage behaves not as expected
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?
>> 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.
> 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.
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
way that is described as "standard" for Debian), with a special option
or hook that does this for those who really need it (and know what they
are doing).
> 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?
Best regards
Ole
Reply to: