Le Mon, Nov 04, 2013 at 08:17:39AM +0100, Raphael Hertzog a écrit :
>
> To avoid unexpected changes, we changed this a long time ago (dpkg 1.16.1)
> when we introduced "dpkg-source --commit" to actually record the changes
> in a new patch.
>
> Maybe the whole processe should be documented as:
> 1
On Mon, Nov 04, 2013 at 02:46:17PM +0100, Raphael Hertzog wrote:
> On Mon, 04 Nov 2013, Bill Allombert wrote:
> > Such policy change should have been proposed before --commit was
> > implemented.
> > dpkg is supposed to follow policy not the other way round.
>
> No, the policy doesn't dictate eve
On Mon, 04 Nov 2013, Bill Allombert wrote:
> Such policy change should have been proposed before --commit was implemented.
> dpkg is supposed to follow policy not the other way round.
No, the policy doesn't dictate everything top-down. Large part of it are
built on top of existing practices that i
On Mon, Nov 04, 2013 at 08:17:39AM +0100, Raphael Hertzog wrote:
> Maybe the whole processe should be documented as:
> 1/ dpkg-source -x
> 2/ do the changes
> 3/ dpkg-source --commit
> 4/ dpkg-buildpackage
>
> > With the removal of the parenthetical, this looks good to me. Seconded.
>
> With the
On Tue, 29 Oct 2013, Russ Allbery wrote:
> > In general, when using source format 3.0 (quilt) or later, running
> > `dpkg-source -x' on a source package will produce the source of
> > the package, ready for editing. This will allow one to make
> > changes and run `dpkg-buildpackage
On 29/10/13 16:35, Russ Allbery wrote:
> Ximin Luo writes:
>
>> It depends on what you consider as "part of the build process". Now that
>> you are deprecating the "patch" target, I would argue that "ready to
>> build" and "ready to modify" are the same thing - since `dpkg-source
>> --before-buil
Ximin Luo writes:
> It depends on what you consider as "part of the build process". Now that
> you are deprecating the "patch" target, I would argue that "ready to
> build" and "ready to modify" are the same thing - since `dpkg-source
> --before-build` applies the patches, which is also what you
On 29/10/13 15:32, Russ Allbery wrote:
> Ximin Luo writes:
>
>> I assumed that "extract to modified-build-ready" is the same as "extract
>> to build-ready". In other words, if you can "edit" then "produce a
>> modified package", then the you can also *not* perform the editing step
>> and just "pr
Julian Gilbey writes:
> That's a good point: with the not-so-recent introduction of the
> recommended source format 3.0 (quilt) for non-native packages, there
> should probably be two changes:
> * In section 4.9, the `patch' target should be labelled as
> (deprecated) instead of (optional), an
On Tue, Oct 29, 2013 at 01:25:57PM +, Ximin Luo wrote:
> Not having to support "patch" greatly simplifies things, but "deprecation" is
> not mentioned anywhere in Section 4... Do you know how many existing packages
> still use "patch"?
That's a good point: with the not-so-recent introduction
Ximin Luo writes:
> I assumed that "extract to modified-build-ready" is the same as "extract
> to build-ready". In other words, if you can "edit" then "produce a
> modified package", then the you can also *not* perform the editing step
> and just "produce an unchanged package". Likewise, if the f
On 29/10/13 14:30, Bill Allombert wrote:
> On Tue, Oct 29, 2013 at 01:25:57PM +, Ximin Luo wrote:
>> The wording of 4.14 is not consistent with that interpretation:
>>
>> "If running dpkg-source -x on a source package doesn't [..] allow one to [..]
>> run dpkg-buildpackage to produce a modified
On Tue, Oct 29, 2013 at 01:25:57PM +, Ximin Luo wrote:
> The wording of 4.14 is not consistent with that interpretation:
>
> "If running dpkg-source -x on a source package doesn't [..] allow one to [..]
> run dpkg-buildpackage to produce a modified package [..], creating a
On 29/10/13 13:15, Bill Allombert wrote:
> On Tue, Oct 29, 2013 at 12:41:45PM +, Ximin Luo wrote:
>> Package: debian-policy
>> Severity: important
>>
>> I was recently hit by this bug [1] which stems from inconsistent assumptions
>> that various build tools have about the state of the build tre
On Tue, Oct 29, 2013 at 12:41:45PM +, Ximin Luo wrote:
> Package: debian-policy
> Severity: important
>
> I was recently hit by this bug [1] which stems from inconsistent assumptions
> that various build tools have about the state of the build tree. I filed [2]
> to devscripts to suggest a fix
Package: debian-policy
Severity: important
I was recently hit by this bug [1] which stems from inconsistent assumptions
that various build tools have about the state of the build tree. I filed [2]
to devscripts to suggest a fix.
However, policy wording could be better in this area, and it is espe
16 matches
Mail list logo