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
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 and
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
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
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#72335
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 poluted with
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
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
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
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 ...] target
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 bug.
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 ...] target
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 BTS?
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 and
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 a
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 Debian.
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
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 to
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
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 (if
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 see
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 (i.e.
28 matches
Mail list logo
