Re: Bug#250202: Standardizing make target for 'patch' and 'upstream-source'
[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
Reply to: