Re: debuild/dpkg-buildpackage behaves not as expected
debian-de...@liska.ath.cx (Olе Streicher) writes: Goswin von Brederlow goswin-...@web.de writes: debian-de...@liska.ath.cx (Ole Streicher) writes: 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. It does not since it keeps the compiled files. If you mean it serious with restoring the state, you should call clean here, too. The state of the patches. 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 [...] You can do the same even if either clean is called before the unpatching was done, or if neither clean nor unpatching was done, since quilt recognizes the state. If the patches aren't rolled back to foo.patch after build then the files will differ. If you still have the file open in an editor then editing it will destroy stuf. And quilt refresh will refresh the topmost patch and not foo.patch as intended. So no, you can't do the same without the patch state being restored. The point is really: The state * compiled files (*.o etc.) from a patched package, but * unpatched source files is inconsistent. In a good way. :) Best regards Ole MfG Goswin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87k3zmdxvd.fsf@frosties.localnet
Re: debuild/dpkg-buildpackage behaves not as expected
debian-de...@liska.ath.cx (Olе Streicher) writes: Goswin von Brederlow goswin-...@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 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87txyvmidm.fsf@frosties.localnet
Re: debuild/dpkg-buildpackage behaves not as expected
Goswin von Brederlow goswin-...@web.de writes: debian-de...@liska.ath.cx (Ole Streicher) writes: 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. It does not since it keeps the compiled files. If you mean it serious with restoring the state, you should call clean here, 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 [...] You can do the same even if either clean is called before the unpatching was done, or if neither clean nor unpatching was done, since quilt recognizes the state. The point is really: The state * compiled files (*.o etc.) from a patched package, but * unpatched source files is inconsistent. Best regards Ole -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/ytzsjef6zu1@news.ole.ath.cx
Re: debuild/dpkg-buildpackage behaves not as expected
Goswin von Brederlow goswin-...@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 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/ytzzk926l53@news.ole.ath.cx
Re: debuild/dpkg-buildpackage behaves not as expected
debian-de...@liska.ath.cx (Olе Streicher) writes: Goswin von Brederlow goswin-...@web.de writes: debian-de...@liska.ath.cx (Olõ Streicher) writes: James McCoy vega.ja...@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
Re: debuild/dpkg-buildpackage behaves not as expected
debian-de...@liska.ath.cx (Olе Streicher) writes: James McCoy vega.ja...@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. 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. Since for Debian you have only changes in the debian/ subdirectory, you may do the following: vcs clone repository with unpatched source cd repo tweak a little ... dpkg-buildpackage; # applies patches, builds, and unapplies patches vcs diff debian vcs commit debian this does not require unpatching, since it commits only the debian subdirectory, which is not affected by any patches. Therefore, I don't see that the workflow you mentioned is a use case that would require unpatching. [Quoting restored: Goswin wrote] What happens if you now call debuild patch to apply the patches in a 3.0 (quilt) package that has patch/unpatch targets? because it does *not* leave the sources in the same state. Yes, it does. He wrote it himself: 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. If you started with patches applied, then they will still be applied after calling dpkg-buildpackage. If you didn't have patches applied, then dpkg-buildpackage will apply the patches, build and unapply the patches. We discussed the debuild patch option here which was introduced by Goswin. Best Ole 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. 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. 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). I usualy never call clean directly so the above problem can't even arise. MfG Goswin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/8762btlniv.fsf@frosties.localnet
Enforce clean before unpatch (was: Re: debuild/dpkg-buildpackage behaves not as expected)
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. Policy states that clean must revert any changes made during build, but no policy states that no source file must be modified during build. This is therefore not a reasonable assumption to expect that you can unpatch before cleaning in the general case. [...] 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? 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 :-) [...] 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. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4fb64390.8040...@free.fr
Re: debuild/dpkg-buildpackage behaves not as expected
Goswin von Brederlow goswin-...@web.de writes: debian-de...@liska.ath.cx (Olе Streicher) writes: James McCoy vega.ja...@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? -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87txzdlkiv@news.ole.ath.cx
Re: debuild/dpkg-buildpackage behaves not as expected
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Le 17/05/12 00:25, James McCoy a écrit : 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 Precisely, the point is that should be: applies patches, builds, *cleans* and unapplies patches because it does *not* leave the sources in the same state. Yes, it does. Nope. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk+0mOMACgkQ+37NkUuUiPHvwQCfZ5JgYpy9gMl05G+Crkqui+cx BG8AnAj2RKjSNZ8DqFVXFXaWP2nJP+hY =DgDT -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4fb498e3.7060...@users.sourceforge.net
Re: debuild/dpkg-buildpackage behaves not as expected
On Thu, May 17, 2012 at 08:21:23AM +0200, Thibaut Paumard wrote: Le 17/05/12 00:25, James McCoy a écrit : 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 Precisely, the point is that should be: applies patches, builds, *cleans* and unapplies patches So, you would want dpkg-buildpackage to be an expensive no-op? Running the clean target means that you no longer have the artifacts produced by the build. -- James GPG Key: 4096R/331BA3DB 2011-12-05 James McCoy james...@debian.org signature.asc Description: Digital signature
Re: debuild/dpkg-buildpackage behaves not as expected
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Le 17/05/12 11:39, James McCoy a écrit : On Thu, May 17, 2012 at 08:21:23AM +0200, Thibaut Paumard wrote: Le 17/05/12 00:25, James McCoy a écrit : 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 Precisely, the point is that should be: applies patches, builds, *cleans* and unapplies patches So, you would want dpkg-buildpackage to be an expensive no-op? Running the clean target means that you no longer have the artifacts produced by the build. Except the built packages in the parent directory, of course. I see two reasonable choices: 1- don't clean, don't unpatch 2- clean, unpatch (like with -tc) The current default (don't clean, unpatch) doesn't sound as a very good choice to me, but again I may fail to see a use case that is obvious to someone else. Regards, Thibaut. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk+00NQACgkQ+37NkUuUiPF1uACfTk/GvlAIJ7qLNmFzh2Xml/KP 0swAniYd9cOJJmbDkAa1gvqfS+CSRRdM =sokZ -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4fb4d0d4.2030...@users.sourceforge.net
Re: debuild/dpkg-buildpackage behaves not as expected
James McCoy vega.ja...@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. Since for Debian you have only changes in the debian/ subdirectory, you may do the following: vcs clone repository with unpatched source cd repo tweak a little ... dpkg-buildpackage; # applies patches, builds, and unapplies patches vcs diff debian vcs commit debian this does not require unpatching, since it commits only the debian subdirectory, which is not affected by any patches. Therefore, I don't see that the workflow you mentioned is a use case that would require unpatching. [Quoting restored: Goswin wrote] What happens if you now call debuild patch to apply the patches in a 3.0 (quilt) package that has patch/unpatch targets? because it does *not* leave the sources in the same state. Yes, it does. He wrote it himself: 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). If you started with patches applied, then they will still be applied after calling dpkg-buildpackage. If you didn't have patches applied, then dpkg-buildpackage will apply the patches, build and unapply the patches. We discussed the debuild patch option here which was introduced by Goswin. Best Ole -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87ipfvm17v@news.ole.ath.cx
debuild/dpkg-buildpackage behaves not as expected
Hi, I just discovered that debuild does not behave as I would expect from the maintainer's guide [1]: | Cleaning the source and rebuilding the package from your user account | is as simple as: | $ debuild [...] | You can clean the source tree as simply as: | $ debuild clean This gives an error if the dh_clean does not work on the unpatched source, since debuild reverts all patches, but debuild clean does not apply then. I filed a bug report for this [2], including a simple example package, but the maintainer doesn't see a problem here. For me, the behaviour doesn't look good since the state after debuild does not make sense to me: all files created during the build process (from the patches sources) are still there (including temporary ones), but the sources themself do not are not patched anymore. So, build results and sources do not fit together after this step. Even more, if during the build process one file that has a Debian patch is changed, unapplying the patch may fail even if the build change would be reverted during the clean process. What is the rationale behind the automatic reversal of the applied patches before a cleanup? Cheers Ole [1] http://www.debian.org/doc/manuals/maint-guide/build.en.html#debuild [2] http://bugs.debian.org/672378 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/ytzfwb08v2m@news.ole.ath.cx
Re: debuild/dpkg-buildpackage behaves not as expected
On Wed, May 16, 2012 at 09:05:21AM +0200, Olе Streicher wrote: I just discovered that debuild does not behave as I would expect from the maintainer's guide [1]: | Cleaning the source and rebuilding the package from your user account | is as simple as: | $ debuild [...] | You can clean the source tree as simply as: | $ debuild clean This gives an error if the dh_clean does not work on the unpatched source, since debuild reverts all patches, but debuild clean does not apply then. I filed a bug report for this [2], including a simple example package, but the maintainer doesn't see a problem here. (for the reference) ... because debuild is just a wrapper around dpkg-buildpackage and the behavior is documented in dpkg-buildpackage(1). -- WBR, wRAR signature.asc Description: Digital signature
Re: debuild/dpkg-buildpackage behaves not as expected
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Le 16/05/12 09:34, Andrey Rahmatullin a ?crit : On Wed, May 16, 2012 at 09:05:21AM +0200, Olе Streicher wrote: I just discovered that debuild does not behave as I would expect from the maintainer's guide [1]: | Cleaning the source and rebuilding the package from your user account | is as simple as: | $ debuild [...] | You can clean the source tree as simply as: | $ debuild clean This gives an error if the dh_clean does not work on the unpatched source, since debuild reverts all patches, but debuild clean does not apply then. I filed a bug report for this [2], including a simple example package, but the maintainer doesn't see a problem here. (for the reference) ... because debuild is just a wrapper around dpkg-buildpackage and the behavior is documented in dpkg-buildpackage(1). Documented, yes. Rationalized, no. I agree that there's something fishy with the default behaviour: anytime you have to patch a file which is later modified during build, you have to build with -tc IIRC. I agree with Ole that unpatching should never be done before cleaning. Regards, Thibaut. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk+zX6UACgkQ+37NkUuUiPEe5QCfZDjHOHmCeu6GIKXWTPlXOxkS TIoAn1sgi+4ufCCc9yTsnYvR3nVDI5gi =ALCr -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4fb35fa5.5070...@users.sourceforge.net
Re: debuild/dpkg-buildpackage behaves not as expected
On Mi, 16 Mai 2012, Thibaut Paumard wrote:
fishy with the default behaviour: anytime you have to patch a file
which is later modified during build, you have to build with -tc IIRC.
Ouch, I had this case (reautoconf vs patching), it lead me to give
up on it. It simply is not worth the pain.
Best wishes
Norbert
Norbert Preiningpreining@{jaist.ac.jp, logic.at, debian.org}
JAIST, Japan TeX Live Debian Developer
DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5 B094
WOKING (participial vb.)
Standing in the kitchen wondering what you came in here for.
--- Douglas Adams, The Meaning of Liff
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120516085311.gb25...@gamma.logic.tuwien.ac.at
Re: debuild/dpkg-buildpackage behaves not as expected
On Wed, May 16, 2012 at 09:05:21AM +0200, Olе Streicher wrote: What is the rationale behind the automatic reversal of the applied patches before a cleanup? Quoting from the bug I meant to refer you to (#649531) when closing the debuild bug: On one hand, in dpkg's source format v3, the patched source is considered to be standard unpacked form. … On the other hand, some people like to work most of the time with the unpatched source, as in pre-v3 days. … dpkg-source --after-build distinguishes between the two cases by checking for the .pc/.dpkg-source-unapply file, which is added when dpkg-source --before-build notices that patches were not already applied. You can ensure patches remain applied by applying the patches yourself before starting the build. QUILT_PATCHES=debian/patches quilt push -a debuild; # or dpkg-buildpackage, or whatever So, you have a method that you can work with. My main point was that you should be trying to drive change through dpkg, not through devscripts. Cheers, -- James GPG Key: 4096R/331BA3DB 2011-12-05 James McCoy james...@debian.org signature.asc Description: Digital signature
Re: debuild/dpkg-buildpackage behaves not as expected
James McCoy james...@debian.org writes: On Wed, May 16, 2012 at 09:05:21AM +0200, Olе Streicher wrote: What is the rationale behind the automatic reversal of the applied patches before a cleanup? Quoting from the bug I meant to refer you to (#649531) when closing the debuild bug: On one hand, in dpkg's source format v3, the patched source is considered to be standard unpacked form. … On the other hand, some people like to work most of the time with the unpatched source, as in pre-v3 days. That sounds that some people were favoured over standard here. My main point was that you should be trying to drive change through dpkg, not through devscripts. I am not sure who is responsible here -- that's why I've put both commands into the Subject. Cheers Ole -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/ytz8vgs8j43@news.ole.ath.cx
Re: debuild/dpkg-buildpackage behaves not as expected
debian-de...@liska.ath.cx (Olе Streicher) writes: Hi, I just discovered that debuild does not behave as I would expect from the maintainer's guide [1]: | Cleaning the source and rebuilding the package from your user account | is as simple as: | $ debuild [...] | You can clean the source tree as simply as: | $ debuild clean This gives an error if the dh_clean does not work on the unpatched source, since debuild reverts all patches, but debuild clean does not apply then. I filed a bug report for this [2], including a simple example package, but the maintainer doesn't see a problem here. For me, the behaviour doesn't look good since the state after debuild does not make sense to me: all files created during the build process (from the patches sources) are still there (including temporary ones), but the sources themself do not are not patched anymore. So, build results and sources do not fit together after this step. Even more, if during the build process one file that has a Debian patch is changed, unapplying the patch may fail even if the build change would be reverted during the clean process. What is the rationale behind the automatic reversal of the applied patches before a cleanup? What automatic reversal? There is no automatic reversal. The default state of source is with patches applied. % ddsa_0.1-1.dsc dpkg-source: warning: extracting unsigned source package (ddsa_0.1-1.dsc) dpkg-source: info: extracting ddsa in ddsa-0.1 dpkg-source: info: unpacking ddsa_0.1.orig.tar.gz dpkg-source: info: unpacking ddsa_0.1-1.debian.tar.gz dpkg-source: info: applying automake % cd ddsa-0.1/ % debuild ... dpkg-genchanges: including full source code in upload dpkg-source --after-build ddsa-0.1 dpkg-buildpackage: full upload (original source is included) % debuild clean dh clean --with autoreconf dh_testdir dh_auto_clean make[1]: Entering directory `/data/home/brederlo/src/ddsa/ddsa-0.1' test -z || rm -f test . = . || test -z || rm -f rm -f config.status config.cache config.log configure.lineno config.status.lineno rm -f Makefile make[1]: Leaving directory `/data/home/brederlo/src/ddsa/ddsa-0.1' dh_autoreconf_clean dh_clean dpkg-source leaves the source in the same state it finds it before build. So if you start out with patches applied then they stay applied. If you manually removed the patches then it is your job to manually apply them again. Wether debuild target should apply patches before running the target is arguable. But lets say it does apply patches before the target and then restores the source to the state it was before after the target. What happens if you now call debuild patch to apply the patches in a 3.0 (quilt) package that has patch/unpatch targets? Patches would be applied before that patch target is called, then patch is called and does nothing (or fails) and then patches are unapplied again to restore the original state. Not what you want. As a solution to your problem I would add patch/unpatch targets to your source file like this: QUILT=QUILT_PATCHES=debian/patches quilt --quiltrc /dev/null PATCH := $(QUILT) push -a || [ $$($(QUILT) applied) = $$(grep -v '^\#' debian/patches/series) ] UNPATCH := $(QUILT) pop -a || [ $$($(QUILT) applied 21) = No patches applied ] patch: $(PATCH) unpatch: $(UNPATCH) configure-stamp: $(PATCH) ... build: build-stamp build-stamp: configure-stamp $(PATCH) ... clean: $(PATCH) ... # if you like sources unpatched use unapply-patches in # debian/source/local-options or: # $(UNPATCH) The reason for calling PATCH/UNPATCH directly instead of as dependencies is so that (un)patch is called again even if it was called before (because (un)patch might have been called since then) and so that targets with stamp files don't run every time. MfG Goswin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87r4ukp7ts.fsf@frosties.localnet
Re: debuild/dpkg-buildpackage behaves not as expected
Goswin von Brederlow goswin-...@web.de writes: What automatic reversal? There is no automatic reversal. The default state of source is with patches applied. Hmm. I have overlooked this when reading bug report #649531. The order how the steps are applied, is clearly: 1. patch the sources 2. build the package If you want to reverse this, one clearly should to it in reverse order: 1. cleanup from the build process 2. unpatch the sources 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? Wether debuild target should apply patches before running the target is arguable. But lets say it does apply patches before the target and then restores the source to the state it was before after the target. What happens if you now call debuild patch to apply the patches in a 3.0 (quilt) package that has patch/unpatch targets? Patches would be applied before that patch target is called, then patch is called and does nothing (or fails) and then patches are unapplied again to restore the original state. Not what you want. A patch target would contradict your statement dpkg-source leaves the source in the same state it finds it before build. because it does *not* leave the sources in the same state. Cheers Ole -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/ytz4nrg8at2@news.ole.ath.cx
Re: debuild/dpkg-buildpackage behaves not as expected
Hi, On Wed, May 16, 2012 at 09:05:21AM +0200, Olе Streicher wrote: Hi, I just discovered that debuild does not behave as I would expect from the maintainer's guide [1]: You should say :-) I just discovered that debuild does not behave as it is described in the maintainer's guide. So the maintainer's guide can be called buggy but ... | Cleaning the source and rebuilding the package from your user account | is as simple as: | $ debuild [...] | You can clean the source tree as simply as: | $ debuild clean This gives an error if the dh_clean does not work on the unpatched source, since debuild reverts all patches, but debuild clean does not apply then. I filed a bug report for this [2], including a simple example package, but the maintainer doesn't see a problem here. Interesting. For me, the behaviour doesn't look good since the state after debuild does not make sense to me: all files created during the build process (from the patches sources) are still there (including temporary ones), but the sources themself do not are not patched anymore. So, build results and sources do not fit together after this step. Even more, if during the build process one file that has a Debian patch is changed, unapplying the patch may fail even if the build change would be reverted during the clean process. What is the rationale behind the automatic reversal of the applied patches before a cleanup? I do not know. I tends to keep my VCS as patch removed. So I liked debuild to be this way. I happened not to hit case when debuild clean is problematic. (I use debian/source/local-options containing unapply-patches.) It needs to be resolved at dpkg-buildpackage http://bugs.debian.org/649531 with everything considered. This is certainly not debuild problem. Osamu -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120516150354.GA9618@localhost
Re: debuild/dpkg-buildpackage behaves not as expected
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 dpkg-source leaves the source in the same state it finds it before build. I think Goswin meant dpkg-buildpackage here. because it does *not* leave the sources in the same state. Yes, it does. If you started with patches applied, then they will still be applied after calling dpkg-buildpackage. If you didn't have patches applied, then dpkg-buildpackage will apply the patches, build and unapply the patches. -- James GPG Key: 4096R/331BA3DB 2011-12-05 James McCoy james...@debian.org signature.asc Description: Digital signature
