[Cc:s trimmed. Probably should go to -dpkg] On Friday 01 April 2005 02:12, Scott James Remnant wrote: > On Wed, 2005-03-30 at 11:37 +0200, David Schmitt wrote: > > To prepare the sourcecode for inspection and/or minor modifications an > > additional argument for debian/rules would fit well into the current > > model. > > > > Calling "debian/rules prepare" should leave the tree in a state where the > > source is unpacked, all patches are applied and any change to the tree > > would affect the final binaries. > > > > This target should execute without any Build-Depends installed. Though - > > as a intermediate step - it would be appropriate to error out with a > > appropriate message explaining the needed packages and steps to manually > > prepare the source. > > I was initially thinking along these lines myself > <http://www.dpkg.org/NewSourceFormat>, however I'm now starting to lean > towards not allowing arbitrary shell to just open up a source package; > it doesn't "feel" safe enough.
As I wrote in my summary: > "dpkg-source -x" should not default to "prepare"-ing the source since this > is automatically done for building anyways and would be bad security > practice. In the case of "trusted" sources, "dpkg-source --prepare -x *.dsc" can be implemented/used. In the case of untrusted source, the packages has to be examined regardless of what you want to with it (inspection, modification, build). Therefore I think this is a balanced compromise between security and flexibility. > I also don't want to break "cd source-version" as the definitive way to > get to the source afterwards, and am not currently sure how to do that > with packages containing multiple tarballs. Currently, "cd $source-$version" is not /the/ definitive way. If it were, we wouldn't have this discussion. > There's also the issue of how do you clean or put a source package back > together, when it's got the patches all applied -- how do you know which > patch any modifications should go into? I wrote: > Calling "debian/rules prepare" should leave the tree in a state where the > source is unpacked, all patches are applied and any change to the tree would > affect the final binaries. How this is implemented, is left to the build system. My underlying workflow assumptions for local modifications: 1$ dpkg-source --prepare -x foo_1.dsc 2$ cp foo-1 foo-1.prepared 3$ (cd foo-1; [apply needed modifications]) 4$ diff -ru foo-1.prepared foo-1 > foo-mods.patch 5$ (cd foo-1; fakeroot ./debian/rules binary) I recognise that this approach wouldn't work for e.g. official Security NMUs. Though foo-mods.patch should already be quite near the format needed for the build systems. Automating 2$ and 4$ integrated with the build system could combine them into one step before build and add the patch as last patch in the chain to the package. Working with a package - as opposed to applying a small local/security patch - would require a more intimate familarity with the build system anyways. Regards, David -- - hallo... wie gehts heute? - *hust* gut *rotz* *keuch* - gott sei dank kommunizieren wir Ãber ein septisches medium ;) -- Matthias Leeb, Uni f. angewandte Kunst, 2005-02-15
