Wouter Verhelst <[EMAIL PROTECTED]> writes:
> On Wed, Jun 21, 2006 at 02:08:57PM +0200, Goswin von Brederlow wrote:
>> Policy says Build-Depends-Indep must be installed for the build
>> target, which sbuild calls. But sbuild does not install
>> Build-Depends-Indep. Same goes for dpkg-checkbuildep
On Wed, Jun 21, 2006 at 02:08:57PM +0200, Goswin von Brederlow wrote:
> Policy says Build-Depends-Indep must be installed for the build
> target, which sbuild calls. But sbuild does not install
> Build-Depends-Indep. Same goes for dpkg-checkbuildep -B, it does not
> test for Build-Depends-Indep whi
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
Wouter Verhelst <[EMAIL PROTECTED]> writes:
> On Tue, Jun 20, 2006 at 07:52:01PM -0700, Thomas Bushnell BSG wrote:
>> Stephen Gran <[EMAIL PROTECTED]> writes:
>>
>> > This one time, at band camp, Thomas Bushnell BSG said:
>> >> Wouter Verhelst <[EMAIL PROTECTED]> writes:
>> >>
>> >> > Sbuild exp
Stephen Gran <[EMAIL PROTECTED]> writes:
> This one time, at band camp, Thomas Bushnell BSG said:
>> Whenever this has been asked in the past, sbuild has simply declared
>> "this is how I want to do it." I have no idea why.
>>
>> If there is no technical reason for sbuild to behave this way, and
Thomas Bushnell BSG <[EMAIL PROTECTED]> writes:
> Stephen Gran <[EMAIL PROTECTED]> writes:
>
>> This one time, at band camp, Thomas Bushnell BSG said:
>>> Wouter Verhelst <[EMAIL PROTECTED]> writes:
>>>
>>> > Sbuild explicitely, by design, only looks at build-depends. So in order
>>> > for build-
On Tue, Jun 20, 2006 at 07:52:01PM -0700, Thomas Bushnell BSG wrote:
> Stephen Gran <[EMAIL PROTECTED]> writes:
>
> > This one time, at band camp, Thomas Bushnell BSG said:
> >> Wouter Verhelst <[EMAIL PROTECTED]> writes:
> >>
> >> > Sbuild explicitely, by design, only looks at build-depends. So
This one time, at band camp, Thomas Bushnell BSG said:
> Whenever this has been asked in the past, sbuild has simply declared
> "this is how I want to do it." I have no idea why.
>
> If there is no technical reason for sbuild to behave this way, and if
> it does not in fact conform to policy, how
Stephen Gran <[EMAIL PROTECTED]> writes:
> This one time, at band camp, Thomas Bushnell BSG said:
>> 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 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
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
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-d
This one time, at band camp, Thomas Bushnell BSG said:
> 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
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 co
On 19 Jun 2006, Wouter Verhelst said:
> On Mon, Jun 19, 2006 at 01:02:42PM -0500, Manoj Srivastava wrote:
>> On 16 Jun 2006, Goswin Brederlow stated:
>>> The Build-Depends and Build-Conflicts fields must be satisfied
>>> when any target is invoked.
>>
>> Does the converse hold as well? Is Build-D
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
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
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-Con
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 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. Instal
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
>>
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 ti
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 run
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 correctly)
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
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 peo
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
p
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 been
28 matches
Mail list logo
