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.
I reject this
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
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.
hint: send
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.
hint:
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 this
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 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 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 of
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]
References:
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]
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 the form of
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 simple
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]
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
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 @@
/p
p
- If one or both of the targets
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
with it, whereas
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 the
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 parsing, but
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
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
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 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.
This
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 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 be a file
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 component (object)
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
section
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
section
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 this
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 this
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
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
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 them
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 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 maintain
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 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 there is
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 Format
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.
I
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
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
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
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
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 al
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, and
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
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
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.
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 via
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 via
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 al
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.
And once
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 al
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 old thing.
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
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, 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.
Exactly.
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/cost).
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_OPTIONS? It was
* 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-packages
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 debug in
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 benefit
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 the split
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 are
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:
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 version 0
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 this way?:
66 matches
Mail list logo
