Previously Sean 'Shaleh' Perry wrote:
> Debian developers should be able to read and if need be NMU another
> developers package. Allowing rules files to be arbitrary code makes
> this harder.
So are you going to propose to prohibit people to use dbs, yada, debstd,
debhelper or other strange sche
On Sat, Mar 03, 2001 at 04:14:45PM +0100, Gergely Nagy wrote:
> It would make the Policy consistent. Currently, it allows maintainer scripts
> to be anything you would like. The only thing that is required is that they
> must be proper executables. They can even be binaries. Then why does the
> Pol
On Sat, Mar 03, 2001 at 04:14:45PM +0100, Gergely Nagy wrote:
> It would make the Policy consistent. Currently, it allows maintainer scripts
> to be anything you would like. The only thing that is required is that they
> must be proper executables. They can even be binaries. Then why does the
> Pol
Thus spoke Kai Henningsen <[EMAIL PROTECTED]> on 2001-03-03 14:33:00:
> [EMAIL PROTECTED] (Josip Rodin) wrote on 28.02.01 in <[EMAIL PROTECTED]>:
>
> > 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
[EMAIL PROTECTED] (Santiago Vila) wrote on 28.02.01 in <[EMAIL PROTECTED]>:
> 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/
[EMAIL PROTECTED] (Josip Rodin) wrote on 28.02.01 in <[EMAIL PROTECTED]>:
> 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 sh
On Sat, Mar 03, 2001 at 02:48:00PM +0200, Kai Henningsen wrote:
> > These two things aren't demanded by Policy AFAICT, it just so happens that
> > they're possible to be done. Had we used perl or shell as rules file
> > previously, there would be similar things that would be made nonstandard by
> >
[EMAIL PROTECTED] (Josip Rodin) wrote on 01.03.01 in <[EMAIL PROTECTED]>:
> These two things aren't demanded by Policy AFAICT, it just so happens that
> they're possible to be done. Had we used perl or shell as rules file
> previously, there would be similar things that would be made nonstandard
[EMAIL PROTECTED] (Manoj Srivastava) wrote on 01.03.01 in <[EMAIL PROTECTED]>:
> >>"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 r
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
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.
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 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 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 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 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 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
> "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
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
> "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
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 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 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 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
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
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
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
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 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,
>
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 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
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, 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
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: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: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 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
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 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
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, 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
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
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
>
> 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.
>
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
49 matches
Mail list logo
