On Sun, Nov 02, 2003 at 09:47:03PM -0500, Matt Zimmerman wrote:
I'm not sure why libc6 is not essential, but since it is depended upon by
essential packages, it is promoted to essential status anyway. Nothing else
on that list would prevent things like dpkg from working.
I'm copying
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
Package: debian-policy
Version: 3.6.1.0
Severity: wishlist
I noticed that desktop-base package adds local diversion, reported as
Bug#218091. I supposed that this isn't a right thing and is a serious bug.
But I can't find a description of this point in the debian-policy.
Please leaves the local
reassign 218879 debiandoc-sgml
thanks
On Mon, Nov 03, 2003 at 07:50:33AM +, [EMAIL PROTECTED] wrote:
Package: debian-policy
Version: 3.6.1.0
In Package debian-policy_3-1.6.1.0_all.deb you should regenerate files
policy.p[s|df] from
* Anthony Towns aj@azure.humbug.org.au [031101 06:53]:
I'd be more inclined to fix the tools, personally, or to say that
within Debian, we'll translate upstream colons to something else
than removing the support from dpkg or changing its meaning.
Sorry, I have problems parsing this. Does this
On Mon, Nov 03, 2003 at 06:49:41PM +0900, YAMASHITA Junji wrote:
Package: debian-policy
Version: 3.6.1.0
Severity: wishlist
I noticed that desktop-base package adds local diversion, reported as
Bug#218091. I supposed that this isn't a right thing and is a serious bug.
But I can't find a
Processing commands for [EMAIL PROTECTED]:
reassign 218879 debiandoc-sgml
Bug#218879: enumerate list in generated files broken
Bug reassigned from package `debian-policy' to `debiandoc-sgml'.
thanks
Stopping processing here.
Please contact me if you need assistance.
Debian bug tracking
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
Josip Rodin [EMAIL PROTECTED] writes:
It would be nice to have Debian policy available as info packages
for emacs. The best way to do this, I suppose is to have a
seperate package...
% du -ksh policy.info*
12K policy.info
300Kpolicy.info-1
16K policy.info-2
I'm not sure
IMPORTANT: We now carry a full-line of Vicodin, Hydrocodone, Norco products.
Most Reputable Pharmacy on the Internet.
RX Outlet Discount Drugs - We won't be under sold!
New Low prices savings on:
-VICOD1N/Hydrocodone (free shipping)
-Lev1tra
-Norco
-Amb1en
-Phenterm1ne
-Many more!
Next day
On Mon, Nov 03, 2003 at 06:52:08AM +, Colin Watson wrote:
Libraries can't be essential, because it would make it too hard to
remove them when their sonames change.
Understood...but I was actually asking why policy seems to say that a system
lacking Priority: required packages could have a
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.
Your message dated Mon, 3 Nov 2003 17:18:27 +0100
with message-id [EMAIL PROTECTED]
and subject line Bug#119143: Policy Manual as info
has caused the attached Bug report to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your
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?:
37 matches
Mail list logo
