Re: Bug#250202: Standardizing make target for 'patch' and 'upstream-source'

[David Schmitt]

On Friday 01 April 2005 02:12, Scott James Remnant wrote:
> I was initially thinking along these lines myself
> , 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.
>
> 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.
>
> 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?

Adam Heath claims to have a dbs-ng prototype which does "the right thing".

See http://lists.debian.org/debian-devel/2005/04/msg00062.html


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

Re: Bug#250202: Standardizing make target for 'patch' and 'upstream-source'

[Michael Banck]

On Fri, Apr 01, 2005 at 01:12:53AM +0100, 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
> , 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.
> 
> 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.
> 
> 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?

The variance of different build systems present and the strong feelings
DDs have about them is indication that there might not be the
build-system-to-rule-them-all any time soon.  Your proposal definetely
sounds good (especially the "upload patches individually" part), but it
I guess some time will be needed to shake out the problems (after all,
*every* package up to xfree86 will have to be usefully hackable with it)
and transition to it.


In the meantime, having common targets to get to the source (i.e.
"unpack the source(s)", "patch the source(s)", "do both") seems very
desirable to me, this would help when looking at OPP[1]. IMHO, those
targets should be easy words, like "unpack", "patch", "setup", but I
don't care a lot about them as long as we decide on one.

The issue with how to get patches into your new package is not that
important I think, as this is usually rather straight-forward from
looking at what's in debian/patches already.  Also, the 'clean' target
should unapply any patches, so there's no pressing need to have a common
unpatch target (but it wouldn't hurt I guess).


cheers,

Michael

[1] Other People's Packages
-- 
 i am thinking of a smart way of exploiting it and once i
do it will be on slashdot
 WOW SLASHDOT
 ross: well slashdot take any peace of junk


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Bug#250202: Standardizing make target for 'patch' and 'upstream-source'

[David Schmitt]

[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
> , 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

Re: Bug#250202: Standardizing make target for 'patch' and 'upstream-source'

[Marc 'HE' Brockschmidt]

Scott James Remnant <[EMAIL PROTECTED]> writes:
> 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?

Well, the easiest way would be to unpack all patches into
debian/patches. If you want to build the source package, you then
deapply all patches there (well, it moves the point where this fails if
the author changed the source from debian/rules clean to dpkg-source -b)
and then do a normal diff for the rest (like today). This would allow
people to contine their bad habit of keeping all Debian changes in a
.diff.gz-like thing.

Marc
-- 
$_=')(hBCdzVnS})3..0}_$;//::niam/s~=)]3[))_$(rellac(=_$({pam(esrever })e$.)4/3*
)e$(htgnel+23(rhc,"u"(kcapnu ,""nioj ;|_- |/+9-0z-aZ-A|rt~=e$;_$=e${pam tnirp{y
V2ajFGabus} yV2ajFGa&{gwmclBHIbus}gwmclBHI&{yVGa09mbbus}yVGa09mb&{hBCdzVnSbus';
s/\n//g;s/bus/\nbus/g;eval scalar reverse   # 


pgpCx1oi73PAm.pgp
Description: PGP signature

Re: Bug#250202: Standardizing make target for 'patch' and 'upstream-source'

[Scott James Remnant]

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
, 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.

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.

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?

Scott
-- 
Have you ever, ever felt like this?
Had strange things happen?  Are you going round the twist?


signature.asc
Description: This is a digitally signed message part