Re: debuild/dpkg-buildpackage behaves not as expected
debian-devel@liska.ath.cx (Olе Streicher) writes:
> 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.
In which case I remove them in clean since they are not source
files. I'm not a fan of backup+restore for them.
> Another examples are convienence copies of generated files from a parser
Even more so not source. If I generate a .c/.h files from .ll/.y then
they should be removed in the clean targets.
> generator. Or, sometimes Makefiles are going to be *changed* (not even
> regenerated!) by adding/changing dependencies at their end.
Evil. Make support include directives. Put the depends into a seperate
file that is completly generated.
> 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?
I don't require that upstream sources are repackaged. But I don't find
it unreasonable for the clean target to remove non source files even if
upstream does ship them. Note that there is a big difference between
regenerating files and modifying them. Generated files aren't source and
can just be removed in clean.
As for Makefiles: use include.
>> 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
Or you make a patch before calling clean and that won't apply to a clean
copy due to the changes made during build.
>>> "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.
In my case I have a patch target since that is easier to type than
QUILT_PATCHES=debian/patches quilt push -a and because under Lucid
debuild/dpkg-buildpackage does not apply patches before build or
unapplies the after build so I need to do that myself in debian/rules.
Nowadays it is built-in as "dpkg-source --before-build". The patch
target is just a convenience and backward compatibility. And for those
that need a patched source when calling "debuild clean".
>> 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.
Note that it only calls clean with unpatched sources if you specifically
unpatched your source before calling it. The default state is with
patches applied. So you could say that this falls under the "I hope you
know what you are doing" category.
I agree that that it might be benefitial if "debuild clean" could ensure
that patches are applied but I don't see how that could work in general
without interfering with targets which job it would be to apply or
unapply patches. On the other hand it is simple to ensure patches are
applied in debian/rules. That way "fakeroot debian/rules clean" will
also work by first applying the patches.
So I think having the clean target make sure patches are applied if
needed is the better design.
>> 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.
If you have that workflow then changes during build would interfer with
quilt refresh.
I was describing the case of having changes commited to the RCS and
generating debian/patches/* automatically (or a single debian-changes
patch).
> Best regards
>
> Ole
>
> P.S. Would you please not Cc: me as long as you reply to the list?
MfG
Goswin
Reply to: