Re: Enforce clean before unpatch
Thibaut Paumard <mlotpot.news@free.fr> writes:
> Hi,
>
> Le 18/05/12 13:46, Goswin von Brederlow a écrit :
>>> 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. 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.
>
> In an ideal world, every file should be either source or generated.
> Unfortunately in the real world some build systems modify some "source"
> files. Even though, from our point of view, it would be best to get
> upstream fixing this, this is not a reasonable assumption to think that
> we can force them to.
We can't force them but we can force ourself. If the build system
doesn't support out-of-tree builds and you can't fix it to not modify
source files then there still is the simple solution left to simply
create a copy of the source for build purposes. Usualy a hardlinked copy
is enough. In bad cases with those files that get modified (instead of
replaced) changed to a plain copy instead of hardlink.
3.0 (quilt) format and component tarballs makes it easy to copy the
source before build. A simple cp -al component build will do. And in
clean you simply rm -rf build.
Yes, that is ugly. But probably less so than having to backup a bunch of
files before build and restore them in clean because the build system
keeps modifying them.
> Policy states that clean must revert any changes made during build, but
> no policy states that no source file must be modified during build.
Some things you don't do even if policy doesn't dictacte that.
> This is therefore not a reasonable assumption to expect that you can
> unpatch before cleaning in the general case.
Violating that assumption, which is even stronger than assuming clean
can be called without patches applied, leads to all sorts of trouble.
For example what if you type "quilt refresh" to update a path without
having called clean. Suddenly the patch contains the changes done by the
build. Then you call clean and you can no longer unpatch. No thank you.
A build modifying a source file is bad enough. A build modifying a
source file that is also patched is a nightmare.
> [...]
>
>> I ment: It leaves the source in the same state it found it other than
>> the side effects the called target(s) have themself.
>
> And it's the role of the clean target to revert the changes introduced
> by the "build" and "binary" targets...
>
>> [...]
>> 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.
>
> Tanks, that's certainly the point: Ole and I must have missed the
> documentation on this feature. Is it sufficient to make the clean target
> depend on "patch"?
That tends to work usualy but is no garanty.
Say for example I do call
make -f debian/rules binary unpatch clean
I think then, since binary would also depend on patch, the clean target
would not invoke patch and fail because unpatch unapplied all patches.
The example I posted earlier used
clean:
$(PATCH)
...
for that reason and because a phony patch target doesn't mix well with
stamp files.
When you implement something like that make sure you test your targets
with patched unapplied, partially applied and completly applied.
> It's also possible that we simply have to dump a line in
> debian/source/option to get the "-tc" option by default. Any pointer to
> the right option would be welcome. I did look for it, but then: I can't
> even find the butter in the fridge :-)
Don't think so. I think when calling debuild/dpkg-buildpackage with a
traget it simply invokes that target without regard to anything.
>> [...] That means that the build MUST not
>> modify any source files (which is simply evil to begin with)
>
> "Evil" is part of this world.
>
>> [...]
>
> Regards, Thibaut.
MfG
Goswin
Reply to: