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 above
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 it
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 everything
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 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' to
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
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.
I
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 tree. I filed
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 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 package
Ximin Luo infini...@gmx.com 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
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 of the
Julian Gilbey jul...@d-and-j.net 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
On 29/10/13 15:32, Russ Allbery wrote:
Ximin Luo infini...@gmx.com 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
Ximin Luo infini...@gmx.com 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
On 29/10/13 16:35, Russ Allbery wrote:
Ximin Luo infini...@gmx.com 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
16 matches
Mail list logo