Previously Marcus Brinkmann wrote:
> I tried to implement this but failed somehow. Could somebody give a small
> example how to do it in perl?
Changing %ENV should work, since that is also passed along to child
processes.
A very minimal implementation:
#! /usr/bin/perl
$command=pop @ARGV;
forea
On Mon, Jan 11, 1999 at 08:48:55PM +, Jules Bean wrote:
> On Mon, 11 Jan 1999, Marcus Brinkmann wrote:
> > I tried to implement this but failed somehow. Could somebody give a small
> > example how to do it in perl?
> >
> > task: Set a environment variable and run a program which options are in
On Mon, 11 Jan 1999, Marcus Brinkmann wrote:
> I tried to implement this but failed somehow. Could somebody give a small
> example how to do it in perl?
>
> task: Set a environment variable and run a program which options are in an
> array in this environment.
Um..
well, if you're simply trying
Hello,
I have changed the script somewhat. It now tries to guess the default target
gnu os from gcc, and warns if there is some inconsistency.
Also, existing environment is honoured unless -f (force) flag is given.
I was able to build a Debian package with modified versions of
dpkg-buildpackage
On Mon, Jan 11, 1999 at 11:57:02AM +, Jules Bean wrote:
>
> One approach which will work is
>
> env `sh output` sh trial
>
> However, an approach more consistent with the general design of
> enviornment variables would be something like this:
>
> dpkg-env debian/rules binary
>
> Either ex
On Mon, Jan 11, 1999 at 03:28:02PM +1100, Martin Mitchell wrote:
> > I know dpkg-cross, and it does a good job to work around it. Remember it is
> > a _hack_. It's a hack which works quite good, but it is limited due to
> > "broken" debian/rules and upstream Makefiles.
>
> I'd give it more credit
On Mon, 11 Jan 1999, Marcus Brinkmann wrote:
> On Mon, Jan 11, 1999 at 10:09:15AM +, Jules Bean wrote:
> > The standard approach is to eval the output of a program. c.f.
> >
> > eval `ssh-add`
> >
> > as used by ssh.
>
> I will suggest something like this in the documentation then.
>
> I
On Mon, Jan 11, 1999 at 10:09:15AM +, Jules Bean wrote:
> On Sun, 10 Jan 1999, Marcus Brinkmann wrote:
> > Question: Can I modify the environment of the invoking shell from inside a
> > perl script? This would make it easier to use the script.
>
> Nope.
>
> (This is more or less fundamental t
Hi,
On Mon, Jan 11, 1999 at 03:28:02PM +1100, Martin Mitchell wrote:
> Marcus Brinkmann <[EMAIL PROTECTED]> writes:
>
> > > At all?? I think that dpkg-cross does a very reasonable job, and I've not
> > > had to use any 'major hacks' to cross compile packages.
> >
> > I am talking about the debia
On Sun, 10 Jan 1999, Marcus Brinkmann wrote:
> Question: Can I modify the environment of the invoking shell from inside a
> perl script? This would make it easier to use the script.
Nope.
(This is more or less fundamental to the way environment variables work).
The standard approach is to eval t
Marcus Brinkmann <[EMAIL PROTECTED]> writes:
> > At all?? I think that dpkg-cross does a very reasonable job, and I've not
> > had to use any 'major hacks' to cross compile packages.
>
> I am talking about the debian/rules files. There is currently no way to
> write a good debian/rules files for
On Fri, Jan 08, 1999 at 11:34:18AM -0600, Manoj Srivastava wrote:
> I think that having a stand alne script that can be invoked at
> will is better than embedding it in dpkg-buildpackage. After all, I
> may need to know the GNU OS independently of building the whole
> package, in some scri
On Sun, Jan 10, 1999 at 02:01:10PM +, Jules Bean wrote:
>
> Basically, the proposed modifications to support convenient
> cross-compiling, and also to correctly support full architecture/os
> strings, work on setting environment variables.
Yes, I like this.
> Since we might expect
> debian/
On Sat, 9 Jan 1999, Wichert Akkerman wrote:
> Previously Jules Bean wrote:
> > The ability to invoke debian/rules by hand is not really a
> > 'technical advantage', though convenient.
>
> It is an advantage: I do "debian/rules binary" by hand quite a lot in
> testing packages, and only run dpkg-
On Sat, Jan 09, 1999 at 07:28:40PM +1100, Martin Mitchell wrote:
> Marcus Brinkmann <[EMAIL PROTECTED]> writes:
>
> > The only drawback I can see: If you do cross compilation, you can't easily
> > run "debian/rules target" and expect it to work. You'd need to set the
> > variables correctly.
>
>
On Sat, Jan 09, 1999 at 01:59:48AM +0100, Wichert Akkerman wrote:
>
> If I was forced to used dpkg-buildpackage everytime I'ld loose a lot of
> flexibilty which would really annoy me.
Just to avoid confusion in this discussion:
* Nothing in my proposal affects native compilation. (!)
* Nothing i
On Fri, Jan 08, 1999 at 11:34:18AM -0600, Manoj Srivastava wrote:
> Hi,
> >>"Marcus" == Marcus Brinkmann <[EMAIL PROTECTED]> writes:
>
> Marcus> I realized that it should be probably done without adding a
> Marcus> further binary, but directly in dpkg-buildpackage.
>
> I agree with most o
Previously Manoj Srivastava wrote:
> There are too many places where people have made the implicit
> assumption about doing things like make -f debian/rules -n binary
> for this to be changed without good reason, don't you think?
I could interpret this in multiple ways :). Do we really want
I'm not sure everybody knows this, but one of the things I discovered in
one of my weird local packages is that diverting conffiles does work,
although documentation rightly discourages. Just so you know :)
Wichert.
--
On Sat, Jan 09, 1999 at 11:40:13AM -0600, Manoj Srivastava wrote:
> Wichert> Does anyone know why debian/rules is obliged to be a
> Wichert> makefile? I can't find any good reason, except tradition and
> Wichert> ease of maintenance.
>
> Consistency, maybe. It is not as if there is any lo
Hi,
>>"Wichert" == Wichert Akkerman <[EMAIL PROTECTED]> writes:
Wichert> I tried to find a place where that is mentioned, since this
Wichert> I had never heard before the packaging manual is policy.
This issue was discussed here on the mailing list, around the
time I was trying to revi
Manoj Srivastava wrote:
> Wichert> Packaging manual isn't policy. I don't see any reason why a
> Wichert> shell script should not be used for very simply packages..
>
> Packaging manual is too policy. The rationale for that has
> been lost in the mists of time, but this is something that is a
Previously Manoj Srivastava wrote:
> Such a blatant violation of policy was not what I expected
> from someone who is trying to be DPL. If you do indeed do so, that
> package shall immediately draw a bug report.
Relax, I never said I would upload that package to Debian. I have lots
of pack
Previously Manoj Srivastava wrote:
> Packaging manual is too policy. The rationale for that has
> been lost in the mists of time, but this is something that is already
> policy; please float a move to get it changed if you do not like it.
I tried to find a place where that is mentioned, sinc
Marcus Brinkmann <[EMAIL PROTECTED]> writes:
> The only drawback I can see: If you do cross compilation, you can't easily
> run "debian/rules target" and expect it to work. You'd need to set the
> variables correctly.
That's already the case, even before your proposal.
> Currently, cross compila
Hi,
>>"Wichert" == Wichert Akkerman <[EMAIL PROTECTED]> writes:
Wichert> Previously Richard Braakman wrote:
>> It does. Packaging Manual, section 3.2.1, says that debian/rules
>> is an executable makefile that starts with the string `#!/usr/bin/make -f'.
Wichert> Packaging manual isn't polic
Hi,
>>"Wichert" == Wichert Akkerman <[EMAIL PROTECTED]> writes:
Wichert> Wichert. (who has decided to create a package where
Wichert> debian/rules is a sh-script someday just for fun)
Such a blatant violation of policy was not what I expected
from someone who is trying to be DPL. If yo
Previously Jules Bean wrote:
> The ability to invoke debian/rules by hand is not really a
> 'technical advantage', though convenient.
It is an advantage: I do "debian/rules binary" by hand quite a lot in
testing packages, and only run dpkg-buildpackage on the final result.
For some package I only
Previously Richard Braakman wrote:
> It does. Packaging Manual, section 3.2.1, says that debian/rules
> is an executable makefile that starts with the string `#!/usr/bin/make -f'.
Packaging manual isn't policy. I don't see any reason why a shell script
should not be used for very simply packages.
On 8 Jan 1999, Manoj Srivastava wrote:
> Jules> We should simply make dpkg-buildpackage more flexible (so
> Jules> that, for example, in the event you don't want a whole build,
> Jules> you can specify a target - if we don't already have this
> Jules> functionality).
>
> *Chuckle*. Am I
On Fri, 8 Jan 1999, Richard Braakman wrote:
> Jules Bean wrote:
> > Minor glitch - currently, policy doesn't mandate that debian/rules be a
> > make script (and this is probably a good thing). So, dpkg-buildpackage
> > should simply execute debian/rules.
>
> It does. Packaging Manual, section 3
Jules Bean wrote:
> Minor glitch - currently, policy doesn't mandate that debian/rules be a
> make script (and this is probably a good thing). So, dpkg-buildpackage
> should simply execute debian/rules.
It does. Packaging Manual, section 3.2.1, says that debian/rules
is an executable makefile th
Hi,
>>"Marcus" == Marcus Brinkmann <[EMAIL PROTECTED]> writes:
Marcus> I realized that it should be probably done without adding a
Marcus> further binary, but directly in dpkg-buildpackage.
I agree with most of the rest of your analysis, but I still
would prefer to have this pulled out
Hi,
>>"Jules" == Jules Bean <[EMAIL PROTECTED]> writes:
Jules> My gut instincts tell me that encouraging people to use
Jules> dpkg-buildpackage is *good* since this means we can
Jules> incorporate future ideas like this one directly there.
I still think that the functionality should be
On Fri, Jan 08, 1999 at 03:32:37PM +, Jules Bean wrote:
> On Fri, 8 Jan 1999, Marcus Brinkmann wrote:
>
> >
> > So, dpkg-buildpackage would call "make debian/whatever" with following
> > environments:
>
> Minor glitch - currently, policy doesn't mandate that debian/rules be a
> make script (
On Fri, 8 Jan 1999, Marcus Brinkmann wrote:
>
> So, dpkg-buildpackage would call "make debian/whatever" with following
> environments:
Minor glitch - currently, policy doesn't mandate that debian/rules be a
make script (and this is probably a good thing). So, dpkg-buildpackage
should simply exe
On Thu, Jan 07, 1999 at 07:40:42PM +0100, Marcus Brinkmann wrote:
> Using a seperate tool for this has several advantages, as long as this tools
> is
> added to dpkg-dev and we can use it in the rules files (so this additional
> tool should be required, and not optional, for package building purpo
On Thu, Jan 07, 1999 at 11:05:08AM -0700, Jason Gunthorpe wrote:
>
> On 7 Jan 1999, Manoj Srivastava wrote:
>
> > I am fairly convinced that this should be a stand alone
> > program, and not built into dpkg. dpkg knows enough to function as it
> > should, and we should not overload dpkg wit
Hi,
On Thu, Jan 07, 1999 at 03:40:13AM -0600, Manoj Srivastava wrote:
> A lot of this proposal seems to be about providing the rules
> file a means of determining the details of OS/CPU of the build and
> target system to aid in cross compilations. It deals specifically
> with the distinct
On 7 Jan 1999, Manoj Srivastava wrote:
> I am fairly convinced that this should be a stand alone
> program, and not built into dpkg. dpkg knows enough to function as it
> should, and we should not overload dpkg with yet another
I agree. A nice simple package with a short C program would
Hi,
A lot of this proposal seems to be about providing the rules
file a means of determining the details of OS/CPU of the build and
target system to aid in cross compilations. It deals specifically
with the distinct parts that make up a string that GNU builds use to
distinguish target
[ note that this is CC to debian-devel, because it originated there. follow
up's to debian-policy(?) ]
DRAFT: Fixing the architecture query options of dpkg, Version 0.1
=
Abstract: I hope that we can make it easier and cl
42 matches
Mail list logo
