On Fri, Mar 02, 2001 at 12:06:26AM +1000, Anthony Towns wrote:
> On Thu, Mar 01, 2001 at 02:00:59PM +, Julian Gilbey wrote:
> > The two issues:
> > (1) What we demand of packages to comply with policy.
> requirements (MUST) and recommendations (SHOULD)
>
> > (2) What we consider RC.
>
Hi,
debauch is a malloc debugger that I adopted recently.
Before I adopted it, there was already one lintian
warning :
W: debauch: non-dev-pkg-with-shlib-symlink usr/lib/libdebauch.so.0.1
usr/lib/libdebauch.so
debauch contains a script called `debauch' which run the program
to debu
On Fri, Mar 02, 2001 at 10:44:32AM +0100, Jérôme Marant wrote:
> LD_PRELOAD=/usr/lib/libdebauch.so $OBJ $* 2>$OUT
Is the library is never linked against directly, then I think it's best
to put it somewhere other than in /usr/lib/. That removes some
possibility of confusion, both in Lintian an
On Thu, Mar 01, 2001 at 08:54:59PM +0100, Gergely Nagy wrote:
> I have seen debian/rules in Debain that were far worse than this.
> Some of them got rewritten, some might still be there.
>
> Have a look at POP3Lite's debian/rules. It is a makefile, and
> I think it is hared to read than shoop's.
On Thu, Mar 01, 2001 at 09:09:55PM +0100, Gergely Nagy wrote:
> Also, Policy allows the maintainer to have *binary* postinst/whatever
> scripts. The only criteria is that the must be proper executable
> files. I think that if it allows maintainer scripts to be whatever
> the maintainer wants, it sh
Package: debian-policy
Previously Julian Gilbey wrote:
> See bug#72335 (accepted). It'll fall over badly if this behaviour is
> not honoured (which it is by make).
I think we found a flaw in the policy process here: policy changes should be
cc'ed to the relevant package maintainer both on the in
On Thu, Mar 01, 2001 at 05:20:47PM +0100, Wichert Akkerman wrote:
> Previously Julian Gilbey wrote:
> > debian/rules -q target
> >
> > exit status: 2 if target does not exist, !=2 otherwise
>
> This has *never* been required, was never documented anywhere, and
> is not needed at all.
See bug#7
On Thu, Mar 01, 2001 at 05:43:28PM +0100, Wichert Akkerman wrote:
> Previously Julian Gilbey wrote:
> > Right. Give a policy diff which specifies *exactly* what interfaces
> > are required of debian/rules.
>
> I'll make some other changes as well. I notice the current policy
> documented is polut
retitle [PROPOSAL] Optional build-arch and build-indep targets for debian/rules
thanks
Previously Julian Gilbey wrote:
> See bug#72335 (accepted).
How can this be accepted if there is no record of a second in the BTS? There
are a
few `this is a good idea' remarks, but no official second (and no
Previously Julian Gilbey wrote:
> Simply not true. Read the source code for dpkg-buildpackage. I'm
> objecting to this until we specify the following (growing) minimal
> interface:
>
> debian/rules [variable=value ...] target [variable=value ...]
I highly object to complicant the interface to d
Processing commands for [EMAIL PROTECTED]:
> retitle 72335 [PROPOSAL] Optional build-arch and build-indep targets for
> debian/rules
Bug#72335: [ACCEPTED 31/10/2000] Optional build-arch and build-indep targets
for debian/rules
Changed Bug title.
> severity 72335 wishlist
Bug#72335: [PROPOSAL] O
I should like to suggest an alteration to policy in respect of package
documentation.
Configuration file locations are oftenn changed for Debian. However the
manual pages still refer to the upstream locations. This makes it very
difficult to find out where to make changes, particularly for new u
On Fri, Mar 02, 2001 at 12:55:01PM +, Oliver Elphick wrote:
> Configuration file locations are oftenn changed for Debian. However the
> manual pages still refer to the upstream locations. This makes it very
> difficult to find out where to make changes, particularly for new users.
Uh, so wha
On Fri, Mar 02, 2001 at 11:48:49AM +0100, Wichert Akkerman wrote:
> Previously Julian Gilbey wrote:
> > Simply not true. Read the source code for dpkg-buildpackage. I'm
> > objecting to this until we specify the following (growing) minimal
> > interface:
> > debian/rules [variable=value ...] targ
Previously Oliver Elphick wrote:
> I think that all documentation must reflect the Debian locations of
> configuration and other files, and that manpages and the like should be
> altered as necessary to achieve this.
I would consider this a normal task for a maintainer and is too obvious
to be in
On Fri, 02 Mar 2001, Oliver Elphick wrote:
> Configuration file locations are oftenn changed for Debian. However the
> manual pages still refer to the upstream locations. This makes it very
> difficult to find out where to make changes, particularly for new users.
AFAIK what you describe is a bu
On Fri, Mar 02, 2001 at 11:48:49AM +0100, Wichert Akkerman wrote:
> Previously Julian Gilbey wrote:
> > Simply not true. Read the source code for dpkg-buildpackage. I'm
> > objecting to this until we specify the following (growing) minimal
> > interface:
> >
> > debian/rules [variable=value ...]
Previously Anthony Towns wrote:
> But, uh, isn't that what you're doing? debian/rules has been a makefile
> forever, allowing it to be anything else doesn't buy anything practical,
It buys us freedom and room to experiment and innovate.
Wichert.
--
__
On Fri, Mar 02, 2001 at 11:46:39AM +0100, Wichert Akkerman wrote:
> retitle [PROPOSAL] Optional build-arch and build-indep targets for
> debian/rules
> thanks
>
> Previously Julian Gilbey wrote:
> > See bug#72335 (accepted).
>
> How can this be accepted if there is no record of a second in the B
On Fri, Mar 02, 2001 at 02:38:41PM +0100, Wichert Akkerman wrote:
> Previously Anthony Towns wrote:
> > But, uh, isn't that what you're doing? debian/rules has been a makefile
> > forever, allowing it to be anything else doesn't buy anything practical,
> It buys us freedom and room to experiment an
Wichert Akkerman wrote:
>Previously Oliver Elphick wrote:
>> I think that all documentation must reflect the Debian locations of
>> configuration and other files, and that manpages and the like should be
>> altered as necessary to achieve this.
>
>I would consider this a normal task for
Anthony Towns wrote:
>
>--Dxnq1zWXvFF0Q93v
>Content-Type: text/plain; charset=us-ascii
>Content-Disposition: inline
>Content-Transfer-Encoding: quoted-printable
>
>On Fri, Mar 02, 2001 at 12:55:01PM +, Oliver Elphick wrote:
>> Configuration file locations are oftenn changed for
Previously Oliver Elphick wrote:
> I have in the past seen people argue that the upstream stuff should
> be left alone.
Many things are argued, but not all are correct. If you follow that
reasoning we would all be DJB-clones..
Wichert.
--
___
On 20010302T114353+0100, Wichert Akkerman wrote:
> We actually should consider another change: something can not become policy
> until there is an existing implementaiton. This rule is also used in the RFC
> process, and works great there.
This particular amendment does not require an implementati
Julian wrote:
> > > debian/rules [variable=value ...] target [variable=value ...]
Actually, it's this:
debian/rules target [variable=value ...]
At least, that's how dpkg-buildpackage does it, the target is always the
first parameter.
Wichert wrote:
> I highly object to complicant the interface
On Fri, Mar 02, 2001 at 10:43:21AM -0300, Henrique M Holschuh wrote:
> I wonder if anyone ever refused doing such a change?
That would be a reason *not* to put it in policy, at least until we
consider the reasons for such a refusal. Policy is supposed to
encode the things we do agree on.
> I ha
On Fri, 02 Mar 2001, Richard Braakman wrote:
> On Fri, Mar 02, 2001 at 10:43:21AM -0300, Henrique M Holschuh wrote:
> > I have doubts we need to add such to policy... Maybe mentioning "make sure
> > you update the location of files in the documentation you are packaging" in
> > the packaging-guide
On 02-Mar-01, 11:25 (CST), Richard Braakman <[EMAIL PROTECTED]> wrote:
> On Fri, Mar 02, 2001 at 10:43:21AM -0300, Henrique M Holschuh wrote:
> > I have doubts we need to add such to policy... Maybe mentioning "make sure
> > you update the location of files in the documentation you are packaging"
> That would be a reason *not* to put it in policy, at least until we
> consider the reasons for such a refusal. Policy is supposed to
> encode the things we do agree on.
That's not true, and it never was. Policy changes often leaves existing
packages in non-compliance. And that's good.
As I s
On Fri, Mar 02, 2001 at 06:18:31PM +0100, Josip Rodin wrote:
> Wichert wrote:
> > I highly object to complicant the interface to debian/rules.
> Anthony wrote:
> > But, uh, isn't that what you're doing?
> No, because allowing non-makefile rules files wouldn't require any changes
> to the interface
30 matches
Mail list logo
