Gergely Nagy wrote:
> As I stated above, the code marked Evil so not evil because it
> does nasty tricks, it just removes some files so I can make
> shoop-dev and shoop-modules a symlink to shoop.
BTW, check out debhelper's -p flag.
--
see shy jo
Thus spoke Julian Gilbey <[EMAIL PROTECTED]> on 2001-03-01 01:22:03:
>
> [...]
> # core methods
> DEBIAN . do_header : 'echo "==> [$($THIS . MAKE_LEVEL)] Making $@" 1>&2
> $THIS . MAKE_LEVEL =q $(expr $($THIS . MAKE_LEVEL) + 1)'
> [...]
I agree. This shouldn't be in the rules file.
> # T
On 20010301T174940+0100, Wichert Akkerman wrote:
> Right, and my argument is that that is wrong. If debian/rules is a
> makefile or not is an implementation detail and should not be specified
> in policy. Policy should specify the interface to it.
I have no problems with this, actually I agree. I
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 things like scripting advise, which
should be in a seperate document.
Previously Antti-Juhani Kaijanaho wrote:
> Also the debian/rules VAR=VALUE ... syntax is used by dpkg-buildpackage.
Thanks for reminding me, I'll change that to use environment variables
instead.
Wichert.
--
/ Generally uninte
Previously Antti-Juhani Kaijanaho wrote:
> That is false. Currently policy defines the interface of a debian/rules
> and even some of its behaviour by saying that it is a Makefile.
Right, and my argument is that that is wrong. If debian/rules is a
makefile or not is an implementation detail and s
On 20010301T172047+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.
It is part of an accepted
On 20010301T152221+0100, Wichert Akkerman wrote:
> I'll make this a proposal then:
>
> Section 5.2 of policy currently dictates that debian/rules has to be
> a makefile. While this is good practice, the only thing that is essential
> is that it is an executable that will respond to the build
On 20010301T155542+, Julian Gilbey wrote:
> In particular, the following should be minimally required:
>
> debian/rules required-target
>
> exit status: 0 if success, non-zero otherwise
>
> debian/rules -q target
>
> exit status: 2 if target does not exist, !=2 otherwise
Also the debia
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.
Wichert.
--
/ Gene
On Thu, Mar 01, 2001 at 03:22:21PM +0100, Wichert Akkerman wrote:
> I'll make this a proposal then:
>
> Section 5.2 of policy currently dictates that debian/rules has to be
> a makefile. While this is good practice, the only thing that is essential
> is that it is an executable that will res
On Thu, Mar 01, 2001 at 01:12:47PM +0100, Josip Rodin wrote:
> On Thu, Mar 01, 2001 at 10:54:48AM +, Julian Gilbey wrote:
> > What *is* reasonable is to say "I don't yet have time to deal with
> > this."
> >
> > So the source dependencies are a MUST, but we don't yet file RC bugs,
> > probably
Package: debian-policy
Previously Anthony Towns wrote:
> It'll have happened during Manoj's incorporation of the packaging-manual
> into policy. See 72949. You'll notice you seconded it... :)
But Manoj said he would remove the non-policy bits from it, and this
would clearly fall in that category
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.
requirements (MUST)
> And the suggestion is that we find some way of
On Thu, Mar 01, 2001 at 10:49:46PM +1000, Anthony Towns wrote:
> On Thu, Mar 01, 2001 at 11:14:58AM +, Julian Gilbey wrote:
> > So we say "Packages MUST specify source dependencies." and in the
> > annex to policy: "Failure to specify source dependencies is currently
> > not RC."
>
> If the MU
On Thu, Mar 01, 2001 at 02:12:04PM +0100, Wichert Akkerman wrote:
> Previously Anthony Towns wrote:
> > On Thu, Mar 01, 2001 at 10:54:48AM +, Julian Gilbey wrote:
> > > [So I guess that we stick with debian/rules MUST be makefiles as
> > > well!]
> > Eh? Until there's an accepted amendment to c
Previously Anthony Towns wrote:
> On Thu, Mar 01, 2001 at 10:54:48AM +, Julian Gilbey wrote:
> > [So I guess that we stick with debian/rules MUST be makefiles as
> > well!]
>
> Eh? Until there's an accepted amendment to change it, yes.
Heh, when did that happen? That has never been obligatory
On Thu, Mar 01, 2001 at 10:54:48AM +, Julian Gilbey wrote:
> On Thu, Mar 01, 2001 at 12:01:40PM +1000, Anthony Towns wrote:
> > On Wed, Feb 28, 2001 at 11:01:53PM +, Julian Gilbey wrote:
> > > I just checked: in policy 3.1.1.1, they were a MUST (section 2.4.2).
> > > I don't know when that
On Thu, Mar 01, 2001 at 11:14:58AM +, Julian Gilbey wrote:
> So we say "Packages MUST specify source dependencies." and in the
> annex to policy: "Failure to specify source dependencies is currently
> not RC."
If the MUST specify source dependencies, it's RC by definition. That was
the whole p
On Thu, Mar 01, 2001 at 02:37:59PM +1100, Brian May wrote:
> that seems to have limited functionality compared with the makefiles I
> have seen.
>
> for instance
>
> debian/rules binary
>
> will not invoke the "build" target automatically. The makefiles I have
> seen will automatically execute t
On Thu, Mar 01, 2001 at 10:54:48AM +, Julian Gilbey wrote:
> What *is* reasonable is to say "I don't yet have time to deal with
> this."
>
> So the source dependencies are a MUST, but we don't yet file RC bugs,
> probably not even normal bugs against missing source dependencies.
We can partia
On Thu, Mar 01, 2001 at 12:36:43AM -0600, Manoj Srivastava wrote:
> So far, the arguments I have heard for removing this
> restrictions have been
> b) Makefiles can be really hard to write!!
FWIW I didn't say that.
> I guess my objection to this reduction of standardization is
> t
On 20010301T103402+, Julian Gilbey wrote:
> (and notwithstanding that we're going to require both or neither), it
> should say that "debian/rules -q with one of the not-provided targets
> ..."
Sounds like a good idea.
--
%%% Antti-Juhani Kaijanaho % [EMAIL PROTECTED] % http://www.iki.fi/ga
On Thu, Mar 01, 2001 at 02:37:59PM +1100, Brian May wrote:
> that seems to have limited functionality compared with the makefiles I
> have seen.
>
> for instance
>
> debian/rules binary
>
> will not invoke the "build" target automatically. The makefiles I have
> seen will automatically execute t
On Tue, Feb 27, 2001 at 10:53:59AM +1000, Anthony Towns wrote:
> I'm stronly against putting things about the future in policy. That
> might not be rational, but we'll see. That said...
I'm not suggesting this. I'm suggesting that we decide whether the
requirement should apply to *every* package
On Thu, Mar 01, 2001 at 10:56:12AM +, Julian Gilbey wrote:
>
> These are real issues; I'm forwarding them to the ftp and ftp-ssl
> maintainers.
When I made ftp provide ftp-client, I thought ftp-client was already a
virtual package. Since this appears not to be the case, I will remove
that pr
On Thu, Mar 01, 2001 at 01:21:27PM +1000, Anthony Towns wrote:
> > This is also a nice piece of advice, but is orthogonal to the
> > suggestion being made.
>
> Uh, reread Sam's message: he was saying that there would be a number of
> guidelines that would always have exceptions, I was disagreeing.
On Thu, Mar 01, 2001 at 02:51:55PM +1100, Brian May wrote:
> > "Julian" == Julian Gilbey <[EMAIL PROTECTED]> writes:
>
> Julian> The ftp and ftp-ssl packages have started providing the
> Julian> ftp-client virtual package. The ncftp package may well do
> Julian> so as well soon.
On Thu, Mar 01, 2001 at 11:57:50AM +1000, Anthony Towns wrote:
> On Thu, Mar 01, 2001 at 02:31:57AM +0100, Josip Rodin wrote:
> >This file must be an architecture-independent non-interactive executable
> >which has to take the following parameters on the command line and act
> >accordin
On Thu, Mar 01, 2001 at 11:52:16AM +1000, Anthony Towns wrote:
> > I'm just
> > going to go and file an important bug against shoop, along with
> > another one for having version number 1.0 yet not being a native
> > package (perhaps that's wrong as he appears to be an upstream devel as
> > well).
On Thu, Mar 01, 2001 at 02:31:57AM +0100, Josip Rodin wrote:
> > I can't think of a really good reason for insisting, besides the issue
> > of readability.
>
> Indeed, and even that's debatable.
And not particularly precisely defined ;-)
> I can't seem to think of proper wording to allow non-mak
On Thu, Mar 01, 2001 at 12:01:40PM +1000, Anthony Towns wrote:
> On Wed, Feb 28, 2001 at 11:01:53PM +, Julian Gilbey wrote:
> > I just checked: in policy 3.1.1.1, they were a MUST (section 2.4.2).
> > I don't know when that got lost. So we'll go back to it.
>
> Must/Should/May only had given
Just playing around with make, and want to suggest this tiny
modification to the proposal: in place of:
+ If one or both of the targets build-arch
+ and build-indep are not provided, then
+ invoking debian/rules with one of the
+
On 20010228T214134+0100, Josip Rodin wrote:
> I would like to propose that the debian/rules file is allowed to be
> non-makefile. Any kind of a program that can do the required stuff can be a
> debian/rules file. We shouldn't prohibit it when someone e.g. writes a short
> shell script or another in
>>"Alex" == Alexander Hvostov <[EMAIL PROTECTED]> writes:
Alex> It can be done the easy way, or the hard way. What you described is the
Alex> hard way. Why can't it be done the easy way?
If people really think that calling scripts from Makefiles is
hard, should they really be maintaini
>>"Anthony" == Anthony Towns writes:
Anthony> I'm stronly against putting things about the future in policy. That
Anthony> might not be rational, but we'll see. That said...
I concur, for what it is worth.
manoj
--
When in doubt, do what the President does -- guess.
Manoj Sri
36 matches
Mail list logo
