Re: debuild/dpkg-buildpackage behaves not as expected
Goswin von Brederlow <goswin-v-b@web.de> writes:
> debian-devel@liska.ath.cx (Olе Streicher) writes:
>> James McCoy <vega.james@gmail.com> writes:
>>> On Wed, May 16, 2012 at 04:23:05PM +0200, Olе Streicher wrote:
>>>> Unpatching the sources *before* the build process was cleaned up makes
>>>> no sense to me at all. Could you provide a use case for that?
>>> As was described in #649531:
>>>
>>> vcs clone <repository with unpatched source>
>>> cd repo
>>> ... tweak a little ...
>>> dpkg-buildpackage; # applies patches, builds, and unapplies patches
>>> vcs diff; # looks good?
>>> vcs commit
>>
>> This works only for the special case that "build" does not change any
>> source file. Otherwise you would also commit the changed source files.
>
> And it better not. There is no excuse for changing source files during
> build.
Welcome to reality. Usually, "configure" scripts are distributed with
(upstream) source on purpose (since they shall provide an easy adoption
to the current enviroment without the need of additional packages), but
they are going to be changed during the packaging.
Another examples are convienence copies of generated files from a parser
generator. Or, sometimes Makefiles are going to be *changed* (not even
regenerated!) by adding/changing dependencies at their end.
Would you really require for all packages using autoconf that they
repackage upstream source in order to get rid of the regenerated files?
And how would you handle the case that a "Makefile" gets a system
dependent dependency extension?
> 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.
>> "patch" was meant as a target that *applies* the patches. Therefore,
>> it does not leave the sources in the same state (since it applies the
>> patches).
> I ment: It leaves the source in the same state it found it other than
> the side effects the called target(s) have themself.
Why would you need to have a local "patch" target? If it is somehow
generally useful, it should be common to all packages -- and than it
could just be builtin as an option into dpkg-buildpackage. Or just use
quilt directly.
> My main point, which I didn't explicitly state, is this:
>
> The way debuild/dpkg-buildpackage/dpkg-source currently behave allow
> maintainers to modify the behaviour by adding something to
> debian/rules. If the clean target needs the patches applied then
> debian/rules can easily make sure that they are.
Since "clean" usually calls the upstream cleanup, its work depends on
whether the upstream cleanup would actually work on the unchanged
package. Trying to apply the "clean" target from the unpatched source on
a directory that is built by the patched source seems to me buggy by
design and just works on accident.
> On the other hand if the clean target doesn't need the patches applied,
> as is the case for 99.9% of all packages then applying them would be
> wastefull.
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.
> Personaly I try to set up all my packages in such a way that clean or
> no clean I can simply commit changes. That means that the build MUST
> not modify any source files (which is simply evil to begin with) and
> that you add a bunch of stuff to the ignore file (e.g. debian/files,
> debian/<pkg>/, debian/*.debhelper.log, debian/*.substvars, stamp
> files, ...). That is something you do once and after that clean or no
> clean you can simply commit. But that requires that patches are
> unapplied after build (unapply-patches in debian/source/local-options
> to enforce this).
It does not, as long as you commit just the debian/ subdirectory. Since
*all* changes you make are in this directory, I don't see why this is a
limitation.
Best regards
Ole
P.S. Would you please not Cc: me as long as you reply to the list?
Reply to: