On Mon, Nov 17, 2003 at 07:01:38PM +0100, Bill Allombert wrote:
> On Thu, Nov 13, 2003 at 07:47:03PM -0600, Adam Heath wrote:
> > On Wed, 12 Nov 2003, Bill Allombert wrote:
> >
> > > Hello,
> > >
> > > I am offering a third patch that implement the Build-Options control
> > > field proposal.
> >
On Fri, 14 Nov 2003, Luca - De Whiskey's - De Vitis wrote:
> On Thu, Nov 13, 2003 at 07:47:03PM -0600, Adam Heath wrote:
> > > I am offering a third patch that implement the Build-Options control
> > > field proposal.
> >
> > I reject this proposal, until such time as the code has implemented it.
On Thu, Nov 13, 2003 at 07:47:03PM -0600, Adam Heath wrote:
> On Wed, 12 Nov 2003, Bill Allombert wrote:
>
> > Hello,
> >
> > I am offering a third patch that implement the Build-Options control
> > field proposal.
>
> I reject this proposal, until such time as the code has implemented it.
>
> h
Hi, Branden Robinson wrote:
> I really like the debian/interfaces proposal.
I don't particularly. Its only advantage, compared to having another entry
in debian/control would be that it's easier to parse.
IMHO that's not strong enough, given that the entry affects other entries
in debian/control
On Fri, Nov 14, 2003 at 04:01:25AM -0600, Luca - De Whiskey's - De Vitis wrote:
> So you are going to implement this even if the discussion is not already
> closed. Of course you can implement it anyway, but it's unfair to ignore what
> Branden Robinson asked:
>
> Message-ID: <[EMAIL PROTECTED]>
>
On Fri, Nov 14, 2003 at 01:54:51PM +, Julian Gilbey wrote:
> In response to Branden's question (does debian/control already have to
> exist when the package is unpacked), I would suggest the following:
>
> Before debian/rules build* is run, one has to check the
> build-dependencies. So at thi
Previously Adam Heath wrote:
> On Sat, 8 Nov 2003, Josip Rodin wrote:
> > (FWIW, I've seen doogie mention thinking of moving debian/ to dpkg/ at some
> > point.)
>
> I don't recall this. However, I could see mv debian deb.
I said that.
Wichert.
--
Wichert Akkerman <[EMAIL PROTECTED]>It is
On Fri, Nov 14, 2003 at 01:49:19PM +0100, Bill Allombert wrote:
> > > I appreciate your efforts, but i'm sorry: i still have not seen a reply to
> > > last mail from Branden:
> > > Message-ID: <[EMAIL PROTECTED]>
> > > References: <[EMAIL PROTECTED]>
> >
> > Please could you provide references in
On Fri, Nov 14, 2003 at 12:38:39PM +, Julian Gilbey wrote:
> On Thu, Nov 13, 2003 at 02:25:13AM -0600, Luca - De Whiskey's - De Vitis
> wrote:
> > I appreciate your efforts, but i'm sorry: i still have not seen a reply to
> > last mail from Branden:
> > Message-ID: <[EMAIL PROTECTED]>
http://
On Fri, Nov 14, 2003 at 12:38:39PM +, Julian Gilbey wrote:
> On Thu, Nov 13, 2003 at 02:25:13AM -0600, Luca - De Whiskey's - De Vitis
> wrote:
> > I appreciate your efforts, but i'm sorry: i still have not seen a reply to
> > last mail from Branden:
> > Message-ID: <[EMAIL PROTECTED]>
> > Refe
On Thu, Nov 13, 2003 at 02:25:13AM -0600, Luca - De Whiskey's - De Vitis wrote:
> I appreciate your efforts, but i'm sorry: i still have not seen a reply to
> last mail from Branden:
> Message-ID: <[EMAIL PROTECTED]>
> References: <[EMAIL PROTECTED]>
Please could you provide references in the form
On Thu, Nov 13, 2003 at 07:47:03PM -0600, Adam Heath wrote:
> > I am offering a third patch that implement the Build-Options control
> > field proposal.
>
> I reject this proposal, until such time as the code has implemented it.
>
> hint: send patches to the bts for dpkg-dev
So you are going to
On Wed, 12 Nov 2003, Bill Allombert wrote:
> Hello,
>
> I am offering a third patch that implement the Build-Options control
> field proposal.
I reject this proposal, until such time as the code has implemented it.
hint: send patches to the bts for dpkg-dev
On Wed, Nov 12, 2003 at 09:35:46PM +0100, Bill Allombert wrote:
> Hello,
>
> I am offering a third patch that implement the Build-Options control
> field proposal.
I appreciate your efforts, but i'm sorry: i still have not seen a reply to
last mail from Branden:
Message-ID: <[EMAIL PROTECTED]>
Re
Hello,
I am offering a third patch that implement the Build-Options control
field proposal.
--- policy.sgml Wed Oct 29 22:49:42 2003
+++ policy.sgml.new3Wed Nov 12 21:25:12 2003
@@ -1856,15 +1856,6 @@
- If one or both of the targets build-arch and
On Mon, Nov 10, 2003 at 11:26:24AM -0600, Adam Heath wrote:
> On Mon, 10 Nov 2003, Branden Robinson wrote:
>
> > Uh, what if I want to put the following at the very top of my
> > debian/control file?
> >
> > # $Id$
> >
> > I was given to understand that dpkg 1.10.15 or so would be just fine
> > wi
On Mon, 10 Nov 2003, Branden Robinson wrote:
> Uh, what if I want to put the following at the very top of my
> debian/control file?
>
> # $Id$
>
> I was given to understand that dpkg 1.10.15 or so would be just fine
> with it, whereas dpkg 1.9.21 or so would vomit all over it.
Placing comments in
On Sat, Nov 08, 2003 at 06:24:09PM -0600, Adam Heath wrote:
> On Fri, 7 Nov 2003, Branden Robinson wrote:
>
> > On Fri, Nov 07, 2003 at 01:02:56PM +0100, Bill Allombert wrote:
> > > Joy proposed to put such information in debian/control instead.
> > >
> > > The idea of a new file was to ease parsi
On Sat, 8 Nov 2003, Josip Rodin wrote:
> (FWIW, I've seen doogie mention thinking of moving debian/ to dpkg/ at some
> point.)
I don't recall this. However, I could see mv debian deb.
On Fri, 7 Nov 2003, Branden Robinson wrote:
> On Fri, Nov 07, 2003 at 01:02:56PM +0100, Bill Allombert wrote:
> > Joy proposed to put such information in debian/control instead.
> >
> > The idea of a new file was to ease parsing, but since it is read by
> > dpkg-buildpackage it should be OK.
>
> T
On Fri, Nov 07, 2003 at 10:42:46PM -0500, Branden Robinson wrote:
> > Joy proposed to put such information in debian/control instead.
> >
> > The idea of a new file was to ease parsing, but since it is read by
> > dpkg-buildpackage it should be OK.
>
> This prevents people from using tricks like
On Sat, Nov 08, 2003 at 03:42:49AM -0600, Luca - De Whiskey's - De Vitis wrote:
> If you put a tag you'll patch the problem, show restricted prospecitves,
> and add more burden to the same component, while we need a more complex
> structure, flatten the resonsibilities of each component and eventua
On Sat, Nov 08, 2003 at 01:19:55AM +0100, Josip Rodin wrote:
> As opposed to putting all that into debian/whathaveyou? I fail to see how
> this makes any difference.
I've not proposed to "put all that in debian/whathaveyou". I've proposed to
put the interface offered/needed by required (end eventu
On Fri, Nov 07, 2003 at 01:02:56PM +0100, Bill Allombert wrote:
> Joy proposed to put such information in debian/control instead.
>
> The idea of a new file was to ease parsing, but since it is read by
> dpkg-buildpackage it should be OK.
This prevents people from using tricks like debian/control
On Fri, Nov 07, 2003 at 08:41:13AM -0600, Luca - De Whiskey's - De Vitis wrote:
> > Yeah. If someone really thinks of changing the control file interface as
> > well, where's the guarantee that debian/ will be in the same place, and
> > that debian/interface won't stand out? I think that putting th
On Fri, Nov 07, 2003 at 01:25:37PM -0600, Luca - De Whiskey's - De Vitis wrote:
> > Yeah. If someone really thinks of changing the control file interface as
> > well, where's the guarantee that debian/ will be in the same place, and
> > that debian/interface won't stand out? I think that putting th
On Fri, Nov 07, 2003 at 02:14:04PM +0100, Josip Rodin wrote:
> Yeah. If someone really thinks of changing the control file interface as
> well, where's the guarantee that debian/ will be in the same place, and that
> debian/interface won't stand out? I think that putting this into the source
> sect
On Fri, Nov 07, 2003 at 02:14:04PM +0100, Josip Rodin wrote:
> Yeah. If someone really thinks of changing the control file interface as
> well, where's the guarantee that debian/ will be in the same place, and that
> debian/interface won't stand out? I think that putting this into the source
> sect
On Fri, Nov 07, 2003 at 01:02:56PM +0100, Bill Allombert wrote:
> > > So, why not a mix of these two? why don't we attach the concept of
> > > interface
> > > to the entire source package?
> > >
> > > debian/interface could be a file in which we describe the interface
> > > implemented by each co
On Thu, Nov 06, 2003 at 01:31:10PM -0500, Branden Robinson wrote:
> On Wed, Nov 05, 2003 at 02:35:44PM -0600, Luca - De Whiskey's - De Vitis
> wrote:
> > So, why not a mix of these two? why don't we attach the concept of interface
> > to the entire source package?
> >
> > debian/interface could b
On Wed, Nov 05, 2003 at 02:35:44PM -0600, Luca - De Whiskey's - De Vitis wrote:
> So, why not a mix of these two? why don't we attach the concept of interface
> to the entire source package?
>
> debian/interface could be a file in which we describe the interface
> implemented by each component (ob
On Wed, Nov 05, 2003 at 02:03:17PM -0600, Adam Heath wrote:
> Instead of Rules-Version: in control, which specifies a single interface
> 'number', how about a Rules-Interface:, which contains a series of flags,
> specifying what features are supported?
>
> I leave it up to this list to decide what
On Tue, 4 Nov 2003, Josip Rodin wrote:
> On Tue, Nov 04, 2003 at 02:04:27AM +, Colin Watson wrote:
> > It's newer and shinier, so it must be better, right?
> >
> > If we're adding optional features, doing so in a way that doesn't
> > confuse people into believing that all packages need to use
On Tue, Nov 04, 2003 at 06:34:23PM +0100, Josip Rodin wrote:
> On Tue, Nov 04, 2003 at 02:04:27AM +, Colin Watson wrote:
> > It's newer and shinier, so it must be better, right?
> >
> > If we're adding optional features, doing so in a way that doesn't
> > confuse people into believing that all
On Tue, Nov 04, 2003 at 02:04:27AM +, Colin Watson wrote:
> It's newer and shinier, so it must be better, right?
>
> If we're adding optional features, doing so in a way that doesn't
> confuse people into believing that all packages need to use them would
> definitely be a good thing, I think.
Josip Rodin wrote:
> Well, regardless of whether we pick versions or listing available targets,
> why not do it with a new control file field in the source section?
> That seems logical, and avoids creating a new file.
>
> It's tangentially relevant that the .dsc and .changes files include a Forma
On Tue, Nov 04, 2003 at 12:32:47AM +0100, Bill Allombert wrote:
> > > (What I dislike is a "format version", mandatory conversion of all
> > > packages to the new format in the long run, and all that).
> >
> > What mandatory conversion to the new format in the long run?
>
> As I see it: currently
On Tue, Nov 04, 2003 at 12:32:47AM +0100, Bill Allombert wrote:
> On Tue, Nov 04, 2003 at 12:10:19AM +0100, Josip Rodin wrote:
> > What mandatory conversion to the new format in the long run?
>
> As I see it: currently there is version 0 and 1. Suppose one
> day version 2 is added. Requirement for
On Mon, Nov 03, 2003 at 11:35:48PM +0100, Santiago Vila wrote:
> On Mon, 3 Nov 2003, Andreas Metzler wrote:
[...]
> > [1] Currently this is only possible with ugliness like making
> > build-indep an empty target and doing the actual expensive work in
> > binary-indep,
> Some of the packages I main
On Tue, 4 Nov 2003, Bill Allombert wrote:
> On Mon, Nov 03, 2003 at 11:35:48PM +0100, Santiago Vila wrote:
> > What about optional fields in the control file with default values:
> >
> > Build-Arch: build
> > Build-Indep: build
> >
> > (and therefore may be omitted), but that can be overridden in
On Tue, Nov 04, 2003 at 12:10:19AM +0100, Josip Rodin wrote:
> > (What I dislike is a "format version", mandatory conversion of all
> > packages to the new format in the long run, and all that).
>
> What mandatory conversion to the new format in the long run?
As I see it: currently there is versi
On Mon, Nov 03, 2003 at 11:35:48PM +0100, Santiago Vila wrote:
> What about optional fields in the control file with default values:
>
> Build-Arch: build
> Build-Indep: build
>
> (and therefore may be omitted), but that can be overridden in this way?:
>
> Build-Arch: build-arch
> Build-Indep: b
On Mon, Nov 03, 2003 at 11:35:48PM +0100, Santiago Vila wrote:
> Packages which do not benefit from a split build-arch / build-indep
> (and there are certainly a lot of packages which do not benefit)
> should continue to be allowed not to have such targets, without people
> or policy saying they ar
On Mon, 3 Nov 2003, Andreas Metzler wrote:
> On Mon, Nov 03, 2003 at 07:49:05PM +0100, Santiago Vila wrote:
> > [...] I would like to see the real benefits from
> > changing the format of debian/rules.
>
> Did you miss the original subject of the thread? The benefit of the
> proposal is to make th
On Mon, Nov 03, 2003 at 07:49:05PM +0100, Santiago Vila wrote:
> On Mon, 3 Nov 2003, Bill Allombert wrote:
> > On Mon, Nov 03, 2003 at 06:09:46PM +0100, Santiago Vila wrote:
> > > What are the real benefits from having build-arch and build-indep?
> > > Are there really so many packages which would
On Mon, Nov 03, 2003 at 06:32:55PM +0100, Bill Allombert wrote:
> On Mon, Nov 03, 2003 at 06:09:46PM +0100, Santiago Vila wrote:
> > What are the real benefits from having build-arch and build-indep?
> > Are there really so many packages which would benefit from having them?
> >
> > (Remember "deb
* Santiago Vila <[EMAIL PROTECTED]> [031103 18:19]:
> What are the real benefits from having build-arch and build-indep?
> Are there really so many packages which would benefit from having them?
The real benefit is that it makes it possible to really use
Build-Indeps, that most multi-binary-packag
On Mon, 3 Nov 2003, Bill Allombert wrote:
> On Mon, Nov 03, 2003 at 06:09:46PM +0100, Santiago Vila wrote:
> > What are the real benefits from having build-arch and build-indep?
> > Are there really so many packages which would benefit from having them?
> >
> > (Remember "debug" in DEB_BUILD_OPTIO
On Mon, Nov 03, 2003 at 06:09:46PM +0100, Santiago Vila wrote:
> What are the real benefits from having build-arch and build-indep?
> Are there really so many packages which would benefit from having them?
>
> (Remember "debug" in DEB_BUILD_OPTIONS? It was removed because its low
> ratio benefit/c
On Mon, 3 Nov 2003, Adam Heath wrote:
> On Mon, 3 Nov 2003, Santiago Vila wrote:
>
> > I object to making the packaging system more complex without a real gain.
>
> Well, without adding complexity, I do agree to having a field that specifies
> the calling procedure for building the package.
Exact
On Mon, 3 Nov 2003, Bill Allombert wrote:
> Some packages generate the control file at build time (e.g. from a
> control.in). We need to access the file before debian/rules is used,
> and debian/control might not exist yet.
debian/rules clean is called very early, and is where debian/control is
On Mon, 3 Nov 2003, Santiago Vila wrote:
> I object to making the packaging system more complex without a real gain.
Well, without adding complexity, I do agree to having a field that specifies
the calling procedure for building the package. However, I don't like
Rules-Format, as it ties us to d
On Mon, Nov 03, 2003 at 01:04:38PM +, Julian Gilbey wrote:
> > > 3.1) Provide an easy and reliable way to tell if the optional targets
> > > are implemented.
> >
> > And once that's there, clarify Policy to say what dpkg-buildpackage et al
> > will do: if optional targets are missing, do the
On Mon, Nov 03, 2003 at 11:01:13AM +0100, Josip Rodin wrote:
> On Mon, Nov 03, 2003 at 09:59:24AM +0100, Bill Allombert wrote:
> > 3.1) Provide an easy and reliable way to tell if the optional targets
> > are implemented.
>
> And once that's there, clarify Policy to say what dpkg-buildpackage et
On Mon, Nov 03, 2003 at 12:59:03PM +, Julian Gilbey wrote:
> On Mon, Nov 03, 2003 at 11:01:13AM +0100, Josip Rodin wrote:
> > On Mon, Nov 03, 2003 at 09:59:24AM +0100, Bill Allombert wrote:
> > > 3.1) Provide an easy and reliable way to tell if the optional targets
> > > are implemented.
> >
On Mon, Nov 03, 2003 at 11:01:13AM +0100, Josip Rodin wrote:
> On Mon, Nov 03, 2003 at 09:59:24AM +0100, Bill Allombert wrote:
> > 3.1) Provide an easy and reliable way to tell if the optional targets
> > are implemented.
>
> And once that's there, clarify Policy to say what dpkg-buildpackage et
On Mon, Nov 03, 2003 at 12:36:15PM +0100, Santiago Vila wrote:
> I object to making the packaging system more complex without a real gain.
>
> We should better document what "Build-Depends-Indep:" really mean:
> That which autobuilders do not need to install to produce Architecture: any
> packages
On Mon, Nov 03, 2003 at 12:36:15PM +0100, Santiago Vila wrote:
> I object to making the packaging system more complex without a real gain.
>
> We should better document what "Build-Depends-Indep:" really mean:
> That which autobuilders do not need to install to produce Architecture: any
> packages
On Mon, Nov 03, 2003 at 11:21:55AM +, Colin Watson wrote:
> dpkg-source already requires debian/control to exist before it calls the
> rules file, so packages already have to make sure debian/control exists
> in their source package, even if they later change it.
Ok, so I retract my objection.
I object to making the packaging system more complex without a real gain.
We should better document what "Build-Depends-Indep:" really mean:
That which autobuilders do not need to install to produce Architecture: any
packages via the clean, build and binary-arch targets only.
We could well keep B
On Mon, Nov 03, 2003 at 11:57:51AM +0100, Bill Allombert wrote:
> Some packages generate the control file at build time (e.g. from a
> control.in). We need to access the file before debian/rules is used,
> and debian/control might not exist yet.
AFAIK they all have the source section, they only a
On Mon, Nov 03, 2003 at 11:57:51AM +0100, Bill Allombert wrote:
> On Mon, Nov 03, 2003 at 11:01:13AM +0100, Josip Rodin wrote:
> > Well, regardless of whether we pick versions or listing available targets,
> > why not do it with a new control file field in the source section?
> > That seems logical
On Mon, Nov 03, 2003 at 11:01:13AM +0100, Josip Rodin wrote:
> On Mon, Nov 03, 2003 at 09:59:24AM +0100, Bill Allombert wrote:
> > 3.1) Provide an easy and reliable way to tell if the optional targets
> > are implemented.
>
> And once that's there, clarify Policy to say what dpkg-buildpackage et
On Mon, Nov 03, 2003 at 09:59:24AM +0100, Bill Allombert wrote:
> 3.1) Provide an easy and reliable way to tell if the optional targets
> are implemented.
And once that's there, clarify Policy to say what dpkg-buildpackage et al
will do: if optional targets are missing, do the old thing. If the o
On Mon, Nov 03, 2003 at 09:59:24AM +0100, Bill Allombert wrote:
> 1.3) Dpkg developer Adam Heath tried to implement the recipe above in
> dpkg-buildpackage but reverted it since it was broken.
[...]
See changelog for 1.10.15.
> 1.4) dpkg-buildpackage -B call 'debian/rules build' and then
> 'debi
Package: debian-policy
Version: 3.6.1
Hello Debian policy,
I would like to fix the problem with Build-Depends-Indep and buid-arch
in current policy.
1) Background:
1.1) Current policy defines two optional debian/rules targets
'build-arch' and 'build-indep'.
1.2) Policy state that
If
66 matches
Mail list logo
