On Wed, 28 Feb 2001 01:38:09 +0100 (CET), Santiago Vila <[EMAIL PROTECTED]>
wrote:
> 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}
On Wed, Feb 28, 2001 at 12:55:16PM +0200, Moshe Zadka wrote:
> On Wed, 28 Feb 2001 01:38:09 +0100 (CET), Santiago Vila <[EMAIL PROTECTED]>
> wrote:
> > On Tue, 27 Feb 2001, Sean 'Shaleh' Perry wrote:
> >
> > > There has not been a consensus on several issues I have raised here:
> > >
> > > what t
On Wed, Feb 28, 2001 at 01:05:32AM -1000, Brian Russo wrote:
> On Wed, Feb 28, 2001 at 12:55:16PM +0200, Moshe Zadka wrote:
> > On Wed, 28 Feb 2001 01:38:09 +0100 (CET), Santiago Vila <[EMAIL PROTECTED]>
> > wrote:
> > > On Tue, 27 Feb 2001, Sean 'Shaleh' Perry wrote:
> > >
> > > > There has not
Package: debian-policy
Version: 3.5.2.0
Severity: wishlist
This proposal has ties to #76868 (invoke-rc.d), #60979 (what /etc/init.d/xxx
restart does?).
"Action" in the text below is the *first* parameter specified for an init
script (e.g.: in /etc/init.d/foo start, "start" is the action).
The na
On 20010226T234331+, Julian Gilbey wrote:
> This allows things like [!i386 m68k], which is equivalent to [!i386]
> but is just plain confusing. So I'd like to deprecate this and allow
> only [arch1 arch2 arch3 ...] or [!arch1 !arch2 !arch3 ...]. The
> wording will become:
Seconded.
--
%%%
Package: debian-policy
Severity: wishlist
Hi,
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 interp
>
> 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 interpreted script, as long as it works.
>
On Feb 28, Sean 'Shaleh' Perry 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
Chris Lawrence wrote:
> I tend to agree with Shaleh. Nothing really to stop debian/rules from
> having lots of calls to a non-makefile though... (debstd *cough* ;-)
>
> I can't think of any case offhand when a makefile *wouldn't* work as
> debian/rules. Even if it does pass the buck totally onto
Package: debian-policy
Version: 3.1.1.1
Section 4.4 says:
> The standard shell interpreter ``/bin/sh'' may be a symbolic link to
> any POSIX compatible shell.
Section 3.3.6 gives examples for init.d scripts using ``echo -n''.
Now POSIX leaves the behaviour of ``echo'' with arguments starting
wi
On Sun, 25 Feb 2001, Julian Gilbey wrote:
> Package: debian-policy
> Version: 3.5.2.0
> Severity: wishlist
>
> Policy should now require packages to specify build time dependencies
> (i.e., packages which require ... MUST specify...)
I just checked: in policy 3.1.1.1, they were a MUST (section 2
On Wed, 28 Feb 2001, Sean 'Shaleh' Perry 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
On 28-Feb-2001 Julian Gilbey wrote:
> On Sun, 25 Feb 2001, Julian Gilbey wrote:
>
>> Package: debian-policy
>> Version: 3.5.2.0
>> Severity: wishlist
>>
>> Policy should now require packages to specify build time dependencies
>> (i.e., packages which require ... MUST specify...)
>
> I just chec
Package: debian-policy
Version: 3.5.2.0
Severity: wishlist
The ftp and ftp-ssl packages have started providing the ftp-client
virtual package. The ncftp package may well do so as well soon. This
package should therefore be included in the virtual packages list.
Julian
--
=-=-=-=-=-=-=-=-=-
On Wed, Feb 28, 2001 at 01:02:00PM -0800, Sean 'Shaleh' Perry 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 sho
On Wed, Feb 28, 2001 at 09:41:34PM +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 scr
Julian,
It can be done the easy way, or the hard way. What you described is the
hard way. Why can't it be done the easy way?
Regards,
Alex.
---
PGP/GPG Fingerprint:
EFD1 AC6C 7ED5 E453 C367 AC7A B474 16E0 758D 7ED9
-BEGIN GEEK CODE BLOCK-
Version: 3.12
GCS/CM>CC/IT d- s:+ a16 C++(++
On Wed, Feb 28, 2001 at 04:27:47PM -0800, Alexander Hvostov wrote:
> Julian,
>
> It can be done the easy way, or the hard way. What you described is the
> hard way. Why can't it be done the easy way?
In general, given the number of example rules files available for
making a package correctly, sur
Your message dated Thu, 1 Mar 2001 00:01:21 +
with message-id <[EMAIL PROTECTED]>
and subject line Bug#88045: Policy is contradictory (I think)
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
On Thu, Mar 01, 2001 at 12:42:48AM +0100, Josip Rodin wrote:
> > I am against this. Grab the shoop package for an example of what this will
> > lead to.
>
> This example actually shows that bluntly prohibiting something like that is
> futile. :)
RC bug, get the package removed until the rules fi
On Thu, Mar 01, 2001 at 12:42:48AM +0100, Josip Rodin wrote:
> Makefiles are already arbitrary code. You can write a makefile rules file
> that would use shoop stuff -- which would be perfectly conformant, but would
> that make it any easier to edit (for the uninitiated)?
But one is much less like
On Thu, Mar 01, 2001 at 12:30:56AM +, Julian Gilbey wrote:
> > > I am against this. Grab the shoop package for an example of what this
> > > will
> > > lead to.
> >
> > This example actually shows that bluntly prohibiting something like that is
> > futile. :)
>
> RC bug, get the package rem
On Thu, Mar 01, 2001 at 12:33:49AM +, Julian Gilbey wrote:
> > Makefiles are already arbitrary code. You can write a makefile rules file
> > that would use shoop stuff -- which would be perfectly conformant, but would
> > that make it any easier to edit (for the uninitiated)?
>
> But one is mu
Julian,
Makefiles can be just as cryptic and difficult to maintain. For this
reason, I don't really agree that using arbitrary code in debian/rules
will make life any more difficult for anyone. It may make life easier,
though.
An example posted to debian-devel illustrated a greatly simplified
deb
On Thu, 1 Mar 2001, Josip Rodin wrote:
> [snip]
> [1] aside from the fact they're computer programs and inherently have no
> ability to care :)
You should try messing around with windows sometime... I think it'll
care. ;)
Regards,
Alex.
---
PGP/GPG Fingerprint:
EFD1 AC6C 7ED5 E453 C367 AC7A
On Thu, Mar 01, 2001 at 01:47:34AM +0100, Josip Rodin wrote:
> On Thu, Mar 01, 2001 at 12:33:49AM +, Julian Gilbey wrote:
> > But one is much less likely to do that: there may be the odd line of
> > code in shoop, but to actually warp the makefile into shoop would seem
> > like hard work.
>
>
On Wed, Feb 28, 2001 at 05:28:33PM -0800, Alexander Hvostov wrote:
> Julian,
>
> Makefiles can be just as cryptic and difficult to maintain. For this
> reason, I don't really agree that using arbitrary code in debian/rules
> will make life any more difficult for anyone. It may make life easier,
>
Julian,
Remember that maintainer scripts aren't altogether uncommon, and writing
shell scripts isn't any harder (by some assessments, easier) than
Makefiles. For this reason, I would assume that most Debian developers are
equally well versed in shell scripts.
Regards,
Alex.
---
PGP/GPG Fingerpr
On Thu, Mar 01, 2001 at 01:40:14AM +0100, Josip Rodin wrote:
> > RC bug, get the package removed until the rules file is readable.
>
> It _is_ readable. :)
To quote a few juicy bits:
[...]
# core methods
DEBIAN . do_header : 'echo "==> [$($THIS . MAKE_LEVEL)] Making $@" 1>&2
$THIS . MAKE
On Thu, Mar 01, 2001 at 01:12:54AM +, Julian Gilbey wrote:
> > > But one is much less likely to do that: there may be the odd line of
> > > code in shoop, but to actually warp the makefile into shoop would seem
> > > like hard work.
> >
> > Considering that make just runs the commands through
Julian,
What about Perl, interpreted Java, Pike, BASIC, et al?
My point: Using interpreted languages in rules files should be
avoided. Otherwise thou canst not build eg python without already having
python installed... and you get a chicken-and-egg problem. Ouch.
Regards,
Alex.
---
PGP/GPG Fin
Juliusz Chroboczek <[EMAIL PROTECTED]> wrote:
> Now POSIX leaves the behaviour of ``echo'' with arguments starting
> with `-' undefined (in order to accomodate both SYSV and BSD versions
> of echo). In addition, POSIX allows echo to be a shell builtin.
>
> Therefore, the script given in 3.3.6 wil
Edward,
I like how you think. That sounds like a fantastic idea!
Regards,
Alex.
---
PGP/GPG Fingerprint:
EFD1 AC6C 7ED5 E453 C367 AC7A B474 16E0 758D 7ED9
-BEGIN GEEK CODE BLOCK-
Version: 3.12
GCS/CM>CC/IT d- s:+ a16 C++()>$ UL>$ P--- L++>++$ E+ W+(-) N+ o? K?
w---()
!O !M
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 meanings in 3.2.1.0, so it was an accepted
amendment to change that must
On Thu, Mar 01, 2001 at 12:30:56AM +, Julian Gilbey wrote:
> RC bug, get the package removed until the rules file is readable.
> This just convinces me that debian/rules MUST be a makefile.
This section comes from the packaging-manual, so I guess the must/should
stuff hasn't really been revi
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
>accordingly:
Or we could go back to how the packaging manual says it:
On Thu, Mar 01, 2001 at 11:57:50AM +1000, Anthony Towns wrote:
> >This file must be an architecture-independent non-interactive executable
> >which has to take the following parameters on the command line and act
> >accordingly:
>
> Or we could go back to how the packaging manual says
On Thu, Mar 01, 2001 at 03:04:32AM +0100, Josip Rodin wrote:
> On Thu, Mar 01, 2001 at 11:57:50AM +1000, Anthony Towns wrote:
> > Or we could go back to how the packaging manual says it:
> > This file is usually an executable makefile, and contains packages
> > specific recipes for compilin
On Tue, Feb 27, 2001 at 09:59:19AM +, Julian Gilbey wrote:
> On Tue, Feb 27, 2001 at 10:45:32AM +1000, Anthony Towns wrote:
> > If, after consideration, you think that one or more of the
> > recommendations (SHOULD) or requirements (MUST) in this document
> > don't apply to your pac
> "Alexander" == Alexander Hvostov <[EMAIL PROTECTED]> writes:
Alexander> My point: Using interpreted languages in rules files
Alexander> should be avoided. Otherwise thou canst not build eg
Alexander> python without already having python installed... and
Alexander> you get a c
Brian,
I don't consider make to be a language. ;)
Regards,
Alex.
---
PGP/GPG Fingerprint:
EFD1 AC6C 7ED5 E453 C367 AC7A B474 16E0 758D 7ED9
-BEGIN GEEK CODE BLOCK-
Version: 3.12
GCS/CM>CC/IT d- s:+ a16 C++()>$ UL>$ P--- L++>++$ E+ W+(-) N+ o? K?
w---()
!O !M !V PS+(++)>+ P
> "Josip" == Josip Rodin <[EMAIL PROTECTED]> writes:
Josip> Imagine a rules file like this:
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 wil
> "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. This package should therefore be
Julian> included in the virtual
43 matches
Mail list logo
