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
> <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.
>
> 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
--
<HostingGeek> i am thinking of a smart way of exploiting it and once i
do it will be on slashdot
<ross> WOW SLASHDOT
<HostingGeek> ross: well slashdot take any peace of junk
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
