On Wed, Feb 28, 2001 at 12:56:38AM +, Julian Gilbey wrote:
> > > there is a mixmatch proposal in the BTS, it needs to be ack'ed by the
> > > policy
> > > group and applied.
> >
> > Yes, I know the number offhand, it's #66023. :|
>
> Reading through the bug report, no clear agreement was reac
On Tue, Feb 27, 2001 at 09:46:08PM +0100, Josip Rodin wrote:
> > there is a mixmatch proposal in the BTS, it needs to be ack'ed by the policy
> > group and applied.
>
> Yes, I know the number offhand, it's #66023. :|
Reading through the bug report, no clear agreement was reached due to
various ex
On Tue, 27 Feb 2001, Sean 'Shaleh' Perry wrote:
> There has not been a consensus on several issues I have raised here:
>
> what to do about cross-compiler directories? Do they belong in /usr/${arch}?
I think they do. GCC explains how to build a cross-compiler, and it
says /usr/local/${arch}, so
> "Gordon" == Gordon Sadler <[EMAIL PROTECTED]> writes:
Gordon> Clarification here. Since libtool is Priority:
Gordon> optional... shouldn't packages that use it Build-depend on
Gordon> it? If so you can use that to determine libtool was used,
Gordon> therefore .la files should
On Tue, Feb 27, 2001 at 09:40:58PM +, Colin Watson wrote:
> Gordon Sadler <[EMAIL PROTECTED]> wrote:
> >On Tue, Feb 27, 2001 at 10:21:44AM -0800, Sean 'Shaleh' Perry wrote:
> >> libtool .la files, how can lintian handle this well?
> >
> >Clarification here. Since libtool is Priority: optional..
>>
> Clarification here. Since libtool is Priority: optional... shouldn't
> packages that use it Build-depend on it? If so you can use that to
> determine libtool was used, therefore .la files should be shipped as
> well?
interesting ..
Gordon Sadler <[EMAIL PROTECTED]> wrote:
>On Tue, Feb 27, 2001 at 10:21:44AM -0800, Sean 'Shaleh' Perry wrote:
>> libtool .la files, how can lintian handle this well?
>
>Clarification here. Since libtool is Priority: optional... shouldn't
>packages that use it Build-depend on it? If so you can use
On Tue, Feb 27, 2001 at 10:21:44AM -0800, Sean 'Shaleh' Perry wrote:
> There has not been a consensus on several issues I have raised here:
>
> what to do about cross-compiler directories? Do they belong in /usr/${arch}?
>
> what to do about shared objects that are not meant to be linked against
On Tue, Feb 27, 2001 at 12:36:46PM -0800, Sean 'Shaleh' Perry wrote:
> >> what to do about shared objects that are not meant to be linked against,
> >> i.e.
> >> plugins?
> >
> > If a .so is not meant to be linked against and is not in a directory for
> > shared libraries (e.g. the linker path), i
On 27-Feb-2001 Josip Rodin wrote:
> On Tue, Feb 27, 2001 at 10:21:44AM -0800, Sean 'Shaleh' Perry wrote:
>> what to do about shared objects that are not meant to be linked against,
>> i.e.
>> plugins?
>
> If a .so is not meant to be linked against and is not in a directory for
> shared libraries
On Tue, Feb 27, 2001 at 10:21:44AM -0800, Sean 'Shaleh' Perry wrote:
> what to do about shared objects that are not meant to be linked against, i.e.
> plugins?
If a .so is not meant to be linked against and is not in a directory for
shared libraries (e.g. the linker path), it's not a shared librar
There has not been a consensus on several issues I have raised here:
what to do about cross-compiler directories? Do they belong in /usr/${arch}?
what to do about shared objects that are not meant to be linked against, i.e.
plugins?
libtool .la files, how can lintian handle this well?
also, I
Processing commands for [EMAIL PROTECTED]:
> retitle 76868 [AMENDMENT 2001-02-27] invoke-rc.d interface to invoke
> initscripts
Bug#76868: [AMMENDMENT 2001-02-27] invoke-rc.d interface to invoke initscripts
Changed Bug title.
> --
Stopping processing here.
Please contact me if you need assistan
On Tue, Feb 20, 2001 at 10:20:36PM +0100, Adrian Bunk wrote:
> > If something has been abandoned for a 1 year and a half, you don't
> > think it's crufty?
>
> Not automatically.
Just as it can't be stated expressly that the packages are abandoned, it
can't be stated that they are not abandoned. I
Processing commands for [EMAIL PROTECTED]:
> retitle 76868 [AMMENDMENT 2001-02-27] invoke-rc.d interface to invoke
> initscripts
Bug#76868: [PROPOSED] invoke-rc.d interface to invoke initscripts
Changed Bug title.
> severity 76868 normal
Bug#76868: [AMMENDMENT 2001-02-27] invoke-rc.d interface t
This is the final "spellchecked" version of the policy diff.
The invoke-rc.d scripts are available in http://people.debian.org/~hmh/
(I think someone might want to test the file-rc one a bit more, it was NOT
tested as much as the sysvinit one).
If there are no objections, this ammendment should
Processing commands for [EMAIL PROTECTED]:
> retitle 72335 [ACCEPTED 31/10/2000] Optional build-arch and build-indep
> targets for debian/rules
Bug#72335: [PROPOSED] Optional build-arch and build-indep targets for
debian/rules
Changed Bug title.
> severity 72335 normal
Bug#72335: [ACCEPTED 31/1
One small correction to the patch provided:
The Build-Depends and
Build-Conflicts fields apply to the targets
- build, binary, binary-arch
- and binary-indep.
+ build, build-arch, binary,
+ binary-arch and bina
Well, I've now gone through the whole of policy making notes and
comments, but rather than write a hugely long email, I'm going to
write a few shorter ones and spread them out over a few weeks so that
people have a chance to digest the material.
Again, I am only going to talk about major things, a
On Tue, Feb 27, 2001 at 10:45:32AM +1000, Anthony Towns wrote:
> If a guideline has exceptions, then they should be documented in policy.
> There are MUST guidelines that'll have exceptions too (such as where
> djbdns packages will put their files, for example).
>
> There aren't any exceptions for
On Tue, Feb 27, 2001 at 10:53:59AM +1000, Anthony Towns wrote:
> One possibility would be to add an extra stage for policy amendments,
> something like [BLOCKED], which a proposal can be placed into if it's
> objected to, but the objectors and proposers agree that the objection
> would be solved if
Package: debian-policy
Version: 3.5.2.0
Severity: wishlist
I would like to deprecate one very confusing part of the Build-Depends
et al syntax. Currently, policy says (section 7.1):
All fields that specify build-time relationships (`Build-Depends',
`Build-Depends-Indep', `Build-Conflic
22 matches
Mail list logo
