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
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 r
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 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
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 d
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
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
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 syst
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
* Anthony Towns [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 mean you have noth
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 p
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 d
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
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 deb
37 matches
Mail list logo
