Wouter Verhelst [EMAIL PROTECTED] writes:
Therefore, if the implementation of sbuild differs from whatever Policy
happens to claim, then Policy is simply wrong.
As state before policy is wrong.
That doesn't mean we can't change both policy and sbuild at the same
time to something that both
Manoj Srivastava [EMAIL PROTECTED] writes:
On 18 Jun 2006, Goswin von Brederlow outgrape:
Peter Eisentraut [EMAIL PROTECTED] writes:
Goswin von Brederlow wrote:
On the other hand the savings can be huge. Think about how many
packages install latex and fonts and generate the documentation
Manoj Srivastava [EMAIL PROTECTED] writes:
On 16 Jun 2006, Goswin Brederlow stated:
the current use and definition of Build-Depends/Conflicts[-Indep] in
policy 7.6 don't match. Both use and definition also greatly reduce
the usefullness of these fields. This issue has come up again and
Wouter Verhelst [EMAIL PROTECTED] writes:
Sbuild explicitely, by design, only looks at build-depends. So in order
for build-depends to be useful at this time if you want a package to
build, you need to list mostly everything in build-depends right now
anyway.
Isn't it sbuild's job to comply
Thomas Bushnell BSG [EMAIL PROTECTED] writes:
Wouter Verhelst [EMAIL PROTECTED] writes:
Sbuild explicitely, by design, only looks at build-depends. So in order
for build-depends to be useful at this time if you want a package to
build, you need to list mostly everything in build-depends
Manoj Srivastava [EMAIL PROTECTED] writes:
Previously, any new feature in dpkg which goes into release
foo gets into policy in release foo + 1. Is there a compelling
reason to diverge from this practice?
manoj
Isn't that for binary packages because otherwise you can't
On Tue, Jun 20, 2006 at 10:50:46AM -0700, Thomas Bushnell BSG wrote:
Wouter Verhelst [EMAIL PROTECTED] writes:
Sbuild explicitely, by design, only looks at build-depends. So in order
for build-depends to be useful at this time if you want a package to
build, you need to list mostly
Guillem Jover [EMAIL PROTECTED] writes:
On Fri, 2006-06-16 at 23:10:36 +0200, Goswin Brederlow wrote:
Package: debian-policy
Severity: normal
[Side note: Buildds/dpkg-buildpackage has no robust way of telling if
the optional build-arch field exists and must call build. This is
wastefull
On 18 Jun 2006, Goswin von Brederlow outgrape:
Peter Eisentraut [EMAIL PROTECTED] writes:
Goswin von Brederlow wrote:
On the other hand the savings can be huge. Think about how many
packages install latex and fonts and generate the documentation
needlessly during build. Installing and
On 16 Jun 2006, Goswin Brederlow stated:
the current use and definition of Build-Depends/Conflicts[-Indep] in
policy 7.6 don't match. Both use and definition also greatly reduce
the usefullness of these fields. This issue has come up again and
again over the last few years and nothing has
On Mon, Jun 19, 2006 at 01:02:42PM -0500, Manoj Srivastava wrote:
On 16 Jun 2006, Goswin Brederlow stated:
The existance of either of the two makes build-arch mandatory.
The old fields change their meaning:
Build-Depends, Build-Conflicts
The Build-Depends and Build-Conflicts fields
Peter Eisentraut [EMAIL PROTECTED] writes:
Goswin von Brederlow wrote:
On the other hand the savings can be huge. Think about how many
packages install latex and fonts and generate the documentation
needlessly during build. Installing and purging latex as well as all
the initex runs and font
On Fri, 2006-06-16 at 23:10:36 +0200, Goswin Brederlow wrote:
Package: debian-policy
Severity: normal
[Side note: Buildds/dpkg-buildpackage has no robust way of telling if
the optional build-arch field exists and must call build. This is
wastefull for both build dependencies and build time.]
Goswin von Brederlow wrote:
On the other hand the savings can be huge. Think about how many
packages install latex and fonts and generate the documentation
needlessly during build. Installing and purging latex as well as all
the initex runs and font generation takes up a awfull lot of time
I
Goswin Brederlow wrote:
Two new fields are introduced:
Build-Depends-Arch, Build-Conflicts-Arch
You are aware, I hope, that the original proposal for the Build-* fields
contained these fields, and they were dropped from the proposal after
several people (buildd admins, if I recall
One question to ask is perhaps whether splitting the build dependencies
into several sets is useful at all, considering that the current state
of having effectively only one useful set has persistent for such a
long time.
Not a lot of people really understand the current definition, and this
Peter Eisentraut [EMAIL PROTECTED] writes:
One question to ask is perhaps whether splitting the build dependencies
into several sets is useful at all, considering that the current state
of having effectively only one useful set has persistent for such a
long time.
Not a lot of people
Package: debian-policy
Severity: normal
Hi,
the current use and definition of Build-Depends/Conflicts[-Indep] in
policy 7.6 don't match. Both use and definition also greatly reduce
the usefullness of these fields. This issue has come up again and
again over the last few years and nothing has
18 matches
Mail list logo
