Michael Banck wrote:
On Mon, May 11, 2009 at 03:17:33PM +0200, Giacomo A. Catenazzi wrote:
So I would like to have a short log (e.g. what I put in stdout/stderr,
with "./configure --quiet"), so that people will have no excuses for
not be carefukll, but also to have access to configure.log (or/an
On Tue, May 19, 2009 at 11:32:05AM +0200, Emilio Pozuelo Monfort wrote:
> Paul Wise wrote:
> > It would be much nicer to discard maintainer-built packages and build
> > everything on the buildds. Then we get build logs as well as the
> > opportunity to replicate Ubuntu's automatically created debug
On Mon, May 11, 2009 at 03:17:33PM +0200, Giacomo A. Catenazzi wrote:
> but I would like to have more :-)
> Currently I prefer to build package with --quiet flag, so that I see
> easily problems on building package:
Neither debuild nor dpkg-buildpackage has a a --quiet flag, so I guess
you weren't
Paul Wise wrote:
> It would be much nicer to discard maintainer-built packages and build
> everything on the buildds. Then we get build logs as well as the
> opportunity to replicate Ubuntu's automatically created debug debs.
Yes! At least discard arch:any debs, so that we don't need to wait until
On Tue, May 12 2009, Steve Langasek wrote:
> On Mon, May 11, 2009 at 10:01:14AM -0700, Russ Allbery wrote:
>> If they're built by the program, then anyone who wants to properly build
>> the software, even if they don't want to go all the way to the package,
>> will need to use the program, since p
On Tue, May 12 2009, Steve Langasek wrote:
> On Sun, May 10, 2009 at 11:30:43PM -0500, Manoj Srivastava wrote:
>> > I'm really surprised to see this approach getting traction. To me,
>> > this seems like a significant, unprecedented departure from the kinds
>> > of interfaces we've mandated in Po
Raphael Hertzog writes:
> On Tue, 12 May 2009, Russ Allbery wrote:
>> Why would you want to disable all hardening instead of filtering out
>> the flag that breaks the package?
> Because no-one has identified the precise flag that breaks the package?
Then filter out the ones that might cause the
Steve Langasek writes:
> Robert Collins' suggestion in <1241989292.8026.20.ca...@lifeless-64>
> seems like a good approach for this, then (modulo the syntax bits, and
> putting the tool in the dpkg-* namespace instead of debhelper's
> namespace).
I like this idea on first glance. It matches wha
"Giacomo A. Catenazzi" writes:
> Could maintainer do a sensible choice of CFLAGS? I don't think so.
> The flags are too much dependent on architecture then the theoretical
> meaning.
Well, maintainers are doing so now and have been since pretty much the
beginning of the packaging format, so clea
On Tue, 12 May 2009, Russ Allbery wrote:
> > The fact that we can filter out some default flags doesn't make it a
> > better approach IMO. If you just want to disable hardening for your
> > package, it would be a pain to have to filter out a possibly evolving
> > list of default flags.
>
> Why wou
On Mon, May 11, 2009 at 10:01:14AM -0700, Russ Allbery wrote:
> If they're built by the program, then anyone who wants to properly build
> the software, even if they don't want to go all the way to the package,
> will need to use the program, since people will write debian/rules such
> that it assu
On Tue, May 12, 2009 at 10:12:20AM +0200, Giacomo A. Catenazzi wrote:
> Steve Langasek wrote:
>> On Sun, May 10, 2009 at 11:41:30PM -0500, Manoj Srivastava wrote:
>>> The only builds Debian supports are not just the buildd ones. As
>>> members of the free software community, we should also
Russ Allbery wrote:
"Giacomo A. Catenazzi" writes:
Manoj Srivastava wrote:
The only builds Debian supports are not just the buildd ones. As
members of the free software community, we should also cater to end
users building, tweaking, and rebuilding our software.
You are a very s
Steve Langasek wrote:
On Sun, May 10, 2009 at 11:41:30PM -0500, Manoj Srivastava wrote:
The only builds Debian supports are not just the buildd ones. As
members of the free software community, we should also cater to end
users building, tweaking, and rebuilding our software.
The only
On Sun, May 10, 2009 at 11:41:30PM -0500, Manoj Srivastava wrote:
> The only builds Debian supports are not just the buildd ones. As
> members of the free software community, we should also cater to end
> users building, tweaking, and rebuilding our software.
The only builds Debian suppo
On Sun, May 10, 2009 at 11:30:43PM -0500, Manoj Srivastava wrote:
> > I'm really surprised to see this approach getting traction. To me,
> > this seems like a significant, unprecedented departure from the kinds
> > of interfaces we've mandated in Policy in the past (i.e., environment
> > variables
Raphael Hertzog writes:
> On Mon, 11 May 2009, Russ Allbery wrote:
>> That seems orthogonal. Either way, you have to get most package
>> maintainers to modify their packages and test to be sure that you can
>> change the default build flags. Either way, the results of that
>> change will produc
On Mon, 11 May 2009, Russ Allbery wrote:
> Raphael Hertzog writes:
> > On Mon, 11 May 2009, Russ Allbery wrote:
>
> >> I still think Build-Options-Supported is fundamentally the wrong way
> >> to implement that. You have to modify every package to add it
> >> anyway, in which case you can just a
Raphael Hertzog writes:
> On Mon, 11 May 2009, Russ Allbery wrote:
>> I still think Build-Options-Supported is fundamentally the wrong way
>> to implement that. You have to modify every package to add it
>> anyway, in which case you can just as easily support it in the
>> package's debian/rules
On Mon, 11 May 2009, Manoj Srivastava wrote:
> > If you refer to the fact, that dpkg-buildpackage cleans and rebuilds
> > everything and that it can take a lot of time, then please stop using
> > arguments that do not hold at all. you can call arbitrary debian/rules
> > targets with dpkg-buildpacka
On Mon, 11 May 2009, Russ Allbery wrote:
> Raphael Hertzog writes:
>
> > BTW, just to make things clear. It's likely that those Makefile
> > snippet (if we decide to go that way) become quite more elaborated as
> > we try integrating support for things like hardening-wrapper (see
> > #489771). E
On Mon, May 11, 2009 at 03:43:41PM +0200, Giacomo A. Catenazzi wrote:
> You are a very special case: a developer since very long time, with a
> enormous knowledge of debian policy (and dpkg internal).
> But I really think that most people outside DD use dpkg-buildpackage
> because it is the easier
"Giacomo A. Catenazzi" writes:
> Manoj Srivastava wrote:
>> The only builds Debian supports are not just the buildd ones. As
>> members of the free software community, we should also cater to end
>> users building, tweaking, and rebuilding our software.
> You are a very special case: a
Raphael Hertzog writes:
> BTW, just to make things clear. It's likely that those Makefile
> snippet (if we decide to go that way) become quite more elaborated as
> we try integrating support for things like hardening-wrapper (see
> #489771). Expect stuff like "if debian/control has
> Build-Optio
On Mon, May 11 2009, Raphael Hertzog wrote:
> On Sun, 10 May 2009, Manoj Srivastava wrote:
>> I would prefer Debian to remain a full fledged member of the free
>> software community, and continue to not let build behaviour diverge
>> whether or not dpkg-buildpackage was used -- which can
Manoj Srivastava wrote:
On Sun, May 10 2009, Steve Langasek wrote:
On Sun, May 10, 2009 at 11:37:46PM +0300, Peter Eisentraut wrote:
On Sunday 10 May 2009 13:56:04 Steve Langasek wrote:
I thought it was generally recognized that it's a Bad Idea to implement
config files using your interpreter
Goswin von Brederlow wrote:
Holger Levsen writes:
Hi,
On Sonntag, 10. Mai 2009, Raphael Hertzog wrote:
With the include approach, we lack this feature and bad/broken local
overrides can't be detected if we only have the build log at hand.
which reminds me that we dont have build logs for pro
On Monday 11 May 2009 09:49:31 Raphael Hertzog wrote:
> On Mon, 11 May 2009, Peter Eisentraut wrote:
> > Well, debuild calls dpkg-buildpackage most of the time, unless you give a
> > specific target (which would again possibly be of interest to those who
> > are interested in calling debian/rules b
On Mon, 11 May 2009, Peter Eisentraut wrote:
> Well, debuild calls dpkg-buildpackage most of the time, unless you give a
> specific target (which would again possibly be of interest to those who are
> interested in calling debian/rules by hand for some reason). And that is also
> something newis
On Sun, 10 May 2009, Manoj Srivastava wrote:
> > If there's any intention at all that Policy eventually mandate use of
> > these Makefile includes, then at a minimum I think Policy needs to
> > *very* tightly constrain what dpkg is allowed to put in those files,
> > to avoid future incompatibilitie
On Monday 11 May 2009 00:06:09 Steve Langasek wrote:
> Or maybe I've misunderstood, and there are
> Debian developers who are building official packages for *upload* by
> calling debian/rules by hand, and that's what people are concerned about
> preserving while still getting the benefits of these
On Sun, 10 May 2009, Manoj Srivastava wrote:
> I would prefer Debian to remain a full fledged member of the free
> software community, and continue to not let build behaviour diverge
> whether or not dpkg-buildpackage was used -- which can be a substancial
> resource hog for multiple bin
On Sun, May 10 2009, Steve Langasek wrote:
> On Sun, May 10, 2009 at 11:37:46PM +0300, Peter Eisentraut wrote:
>> On Sunday 10 May 2009 13:56:04 Steve Langasek wrote:
>> > I thought it was generally recognized that it's a Bad Idea to implement
>> > config files using your interpreter's 'include' f
On Sun, May 10 2009, Raphael Hertzog wrote:
> On Sun, 10 May 2009, Steve Langasek wrote:
>> I'm really surprised to see this approach getting traction. To me, this
>> seems like a significant, unprecedented departure from the kinds of
>> interfaces we've mandated in Policy in the past (i.e., envi
On Sun, May 10 2009, Steve Langasek wrote:
> On Mon, May 04, 2009 at 07:35:18AM +0200, Guillem Jover wrote:
>> * We can set the architecture and default flags (from policy) on the
>> makefile to be included, and packagers will be able to do the change
>> and fix any possible problems (progress
On Mon, May 11, 2009 at 8:02 AM, Goswin von Brederlow wrote:
> Debuild already creates a build log. I think it would be nice to
> include that file in the changes file and have DAK forward it to
> buildd.debian.org for archival. git-buildpackage, svn-buildpackage,
> ... or even dpkg-buildpackage
On Mon, May 11, 2009 at 02:02:47AM +0200, Goswin von Brederlow wrote:
> Debuild already creates a build log. I think it would be nice to
> include that file in the changes file and have DAK forward it to
> buildd.debian.org for archival. git-buildpackage, svn-buildpackage,
> ... or even dpkg-buildp
Holger Levsen writes:
> Hi,
>
> On Sonntag, 10. Mai 2009, Raphael Hertzog wrote:
>> With the include approach, we lack this feature and bad/broken local
>> overrides can't be detected if we only have the build log at hand.
>
> which reminds me that we dont have build logs for probably a lot more
Bill Allombert writes:
> On Sun, May 10, 2009 at 09:54:11PM +0200, Raphael Hertzog wrote:
>> On Sun, 10 May 2009, Steve Langasek wrote:
>> > I'm really surprised to see this approach getting traction. To me, this
>> > seems like a significant, unprecedented departure from the kinds of
>> > inter
Steve Langasek writes:
> On Sun, May 10, 2009 at 11:37:46PM +0300, Peter Eisentraut wrote:
>> On Sunday 10 May 2009 13:56:04 Steve Langasek wrote:
>> > I thought it was generally recognized that it's a Bad Idea to implement
>> > config files using your interpreter's 'include' functionality, but t
On Sun, May 10, 2009 at 11:37:46PM +0300, Peter Eisentraut wrote:
> On Sunday 10 May 2009 13:56:04 Steve Langasek wrote:
> > I thought it was generally recognized that it's a Bad Idea to implement
> > config files using your interpreter's 'include' functionality, but that's
> > basically what we ha
On Sun, 2009-05-10 at 23:37 +0300, Peter Eisentraut wrote:
> On Sunday 10 May 2009 13:56:04 Steve Langasek wrote:
> > I thought it was generally recognized that it's a Bad Idea to implement
> > config files using your interpreter's 'include' functionality, but that's
> > basically what we have here
Hi,
On Sonntag, 10. Mai 2009, Raphael Hertzog wrote:
> With the include approach, we lack this feature and bad/broken local
> overrides can't be detected if we only have the build log at hand.
which reminds me that we dont have build logs for probably a lot more than 25%
(*) of the most used pac
On Sunday 10 May 2009 13:56:04 Steve Langasek wrote:
> I thought it was generally recognized that it's a Bad Idea to implement
> config files using your interpreter's 'include' functionality, but that's
> basically what we have here.
Guillem pointed out one problem: Either you do it via a make inc
On Sun, May 10, 2009 at 09:54:11PM +0200, Raphael Hertzog wrote:
> On Sun, 10 May 2009, Steve Langasek wrote:
> > I'm really surprised to see this approach getting traction. To me, this
> > seems like a significant, unprecedented departure from the kinds of
> > interfaces we've mandated in Policy
On Sun, 10 May 2009, Steve Langasek wrote:
> I'm really surprised to see this approach getting traction. To me, this
> seems like a significant, unprecedented departure from the kinds of
> interfaces we've mandated in Policy in the past (i.e., environment
> variables, executables and command-line
On Sun, May 10, 2009, Steve Langasek wrote:
> I'm really surprised to see this approach getting traction. To me, this
> seems like a significant, unprecedented departure from the kinds of
> interfaces we've mandated in Policy in the past (i.e., environment
> variables, executables and command-line
On Mon, May 04, 2009 at 07:35:18AM +0200, Guillem Jover wrote:
> * We can set the architecture and default flags (from policy) on the
> makefile to be included, and packagers will be able to do the change
> and fix any possible problems (progressive opt-in), but once it's
> included by all pa
On Mon, May 04 2009, Peter Eisentraut wrote:
> On Monday 04 May 2009 23:53:15 Manoj Srivastava wrote:
>> On Mon, May 04 2009, Peter Eisentraut wrote:
>> > Please be sure to use
>> >
>> > FOO = bar
>> >
>> > instead of ":=", unless you have determined that you really wanted ":=".
>> > In most case
On Monday 04 May 2009 23:53:15 Manoj Srivastava wrote:
> On Mon, May 04 2009, Peter Eisentraut wrote:
> > Please be sure to use
> >
> > FOO = bar
> >
> > instead of ":=", unless you have determined that you really wanted ":=".
> > In most cases it won't make a difference, but in some it does, and
On Mon, May 04 2009, Peter Eisentraut wrote:
> On Monday 04 May 2009 08:35:18 Guillem Jover wrote:
>
> I like this proposal. A small nit:
>
>> ,-- /usr/share/dpkg/build-options.mk
>> # distro defaults
>> FOO := distro
>
> Please be sure to use
>
> FOO = bar
>
> instead of ":=", unless you have de
On Monday 04 May 2009 08:35:18 Guillem Jover wrote:
I like this proposal. A small nit:
> ,-- /usr/share/dpkg/build-options.mk
> # distro defaults
> FOO := distro
Please be sure to use
FOO = bar
instead of ":=", unless you have determined that you really wanted ":=". In
most cases it won't m
If we're doing something that ultimately requires modification of
every debian/rules file *anyway*, can we please make
build-arch/build-indep mandatory targets, so that dpkg-buildpackage -B
can *finally* (eight years later!) be changed to call build-arch?
zw
not subscribed to d-devel; please cc:
On Mon, May 04 2009, Raphael Hertzog wrote:
> On Mon, 04 May 2009, Guillem Jover wrote:
>> ,-- debian/rules
>> -include /usr/share/dpkg/build-options.mk
>>
>> # package overrides
>> FOO := pkg
>> `--
>
> Probably without the leading "-", otherwise we have a risk to not have
> any sane default at
On Mon, 04 May 2009, Guillem Jover wrote:
> env var should not be set either, and we should work on getting a
> dpkg-vendor instead, before people try to start using the variable.
FYI, I already started this.
> start fixing packages to include that makefile. The files could look
> something like:
Guillem Jover wrote:
> [ BCCed debian-dpkg for the proposed dpkg changes. ]
> * Lots of packages (roughly around 4k) do not honour env vars for build
> flags, as they follow the examples from policy (or dh-make and similar)
> and thus are setting them unconditionally, which env vars do not
>
On Mon, 2009-05-04 at 07:35 +0200, Guillem Jover wrote:
>
> On Fri, 2009-03-13 at 21:04:30 +0100, Raphael Hertzog wrote:
> > we have an unfortunate situation where the practice in dpkg-buildpackage
> > and the policy do not match fully.
...
> So I think for next dpkg upload we should make dpkg-
On Mon, May 04 2009, Guillem Jover wrote:
> I'll try to summarize the discussion (althought it might be biased to
> my preferred option) and some facts, so that we can get to a conclusion:
+1
I agree with almost everything said in this email.
manoj
--
What use is your matted ha
[ BCCed debian-dpkg for the proposed dpkg changes. ]
Hi!
On Fri, 2009-03-13 at 21:04:30 +0100, Raphael Hertzog wrote:
> we have an unfortunate situation where the practice in dpkg-buildpackage
> and the policy do not match fully.
Ok, had finally the time to read and think about this. I've to say
Matthias Klose writes:
> Manoj Srivastava schrieb:
>> A) Provide a way to specify project wide defaults for env variables
>> B) Allow a site admin to selectively override these, and provide site
>> wide defaults
>> C) Allow a package to set some flags that would otherwise break the
>>
Manoj Srivastava schrieb:
> On Mon, Mar 16 2009, Raphael Hertzog wrote:
>
>> On Sun, 15 Mar 2009, Bill Allombert wrote:
>>> There is no documented semantic for CFLAGS et. al. in Debian policy. While
>>> some Makefile handle it in a certain way, this is not mandatory in
>>> any way. For example so
Raphael Hertzog writes:
> I can understand you were not happy with the way the change was done but
> saying dpkg-bp is broken is strong (and wrong). If you really believed
> that a major mistake was done at that time, you could have complained
> louder and you could have asked for a tech-ctte rul
Manoj Srivastava writes:
> Also, any upstream Makefile that sets CFLAGS (don't most ones
> that use automake do that?) will also be not affected, unless even more
> hackery is done. At this point, what dpkg does to these variables not
> enough to justify any such effort.
Most packages
Hello,
On Wed, 18 Mar 2009, Bill Allombert wrote:
> On Wed, Mar 18, 2009 at 09:53:46AM +0100, Raphael Hertzog wrote:
> > So according to your rule that policy should standardize "common practice"
> > and not mandate something completely new, the env variable proposal is in
> > more widespread usag
On Wed, Mar 18, 2009 at 06:23:55PM +0100, Bill Allombert wrote:
> On Wed, Mar 18, 2009 at 09:53:46AM +0100, Raphael Hertzog wrote:
> > So according to your rule that policy should standardize "common practice"
> > and not mandate something completely new, the env variable proposal is in
> > more wi
On Wed, Mar 18, 2009 at 06:23:55PM +0100, Bill Allombert wrote:
> For ten years, the "common practice" was that dpkg-buildpackage did not set
> any variable.
>
> We cannot standardize on the "env variable proposal" because such proposal has
> never be made. Instead dpkg-buildpackage was broken in
On Wed, Mar 18, 2009 at 09:53:46AM +0100, Raphael Hertzog wrote:
> So according to your rule that policy should standardize "common practice"
> and not mandate something completely new, the env variable proposal is in
> more widespread usage.
For ten years, the "common practice" was that dpkg-buil
On Wed, Mar 18 2009, Raphael Hertzog wrote:
> On Tue, 17 Mar 2009, Manoj Srivastava wrote:
>> On Tue, Mar 17 2009, Stefano Zacchiroli wrote:
>> > It seems to me that you are indeed close, but with the exception of
>> > this required include in all our debian/rules, which will be a PITA to
>> > ach
Raphael Hertzog writes:
> On Tue, 17 Mar 2009, Manoj Srivastava wrote:
>> On Tue, Mar 17 2009, Stefano Zacchiroli wrote:
>> > It seems to me that you are indeed close, but with the exception of
>> > this required include in all our debian/rules, which will be a PITA to
>> > achieve.
>>
>>
On Tue, 17 Mar 2009, Manoj Srivastava wrote:
> On Tue, Mar 17 2009, Stefano Zacchiroli wrote:
> > It seems to me that you are indeed close, but with the exception of
> > this required include in all our debian/rules, which will be a PITA to
> > achieve.
>
> Modulo debhelper, cdbs, et.al ca
On Tue, Mar 17 2009, Stefano Zacchiroli wrote:
> On Tue, Mar 17, 2009 at 11:36:07AM -0500, Manoj Srivastava wrote:
>> # in debian/rules
>> -include /etc/buildpackage.mk
>
> It seems to me that you are indeed close, but with the exception of
> this required include in all our debian/rules, which w
On Tue, Mar 17, 2009 at 11:36:07AM -0500, Manoj Srivastava wrote:
> # in debian/rules
> -include /etc/buildpackage.mk
It seems to me that you are indeed close, but with the exception of
this required include in all our debian/rules, which will be a PITA to
achieve. AFAIU Raphael's proposal, the s
On Mon, Mar 16 2009, Raphael Hertzog wrote:
> On Mon, 16 Mar 2009, Manoj Srivastava wrote:
>> And you are missing the point that making people type stuff on
>> the command line for site specific stuff looses out to being able to
>> edit a conffile instead.
>
> Who said the command line
On Tue, Mar 17 2009, Raphael Hertzog wrote:
> What are the pros mentioned by Manoj that are specific to the Makefile
> snippet approach except the fact that we can continue to call debian/rules
> directly on all packages ?
That by itself is reason enough, I think.
Secondly, I ha
On Mon, 16 Mar 2009, Raphael Geissert wrote:
> Stefano Zacchiroli wrote:
> >
> > ... and pretty please, do not choose a solution that will require
> > adding an "-include" to 15'000 thousands debian/rules; we will finish
> > doing that by Lenny+50, the earliest.
>
> It would take some time, yes;
Stefano Zacchiroli wrote:
>
> ... and pretty please, do not choose a solution that will require
> adding an "-include" to 15'000 thousands debian/rules; we will finish
> doing that by Lenny+50, the earliest.
It would take some time, yes; but packages using cdbs would only require a
binNMU once cd
Raphael Hertzog writes:
> I think we all mostly agree on that. I see only two remarks:
> - the package can either fully override the default settings or
> filter the provided build options: i.e. add/remove/replace build
> options. (and I think that the "filter" option should be the recommende
On Mon, 16 Mar 2009, Manoj Srivastava wrote:
> And you are missing the point that making people type stuff on
> the command line for site specific stuff looses out to being able to
> edit a conffile instead.
Who said the command line was for site-specific stuff?
In my proposition the h
On Mon, 16 Mar 2009, Manoj Srivastava wrote:
> The advantage of the snippet approach is where packages might
> break if the builtin defaults are changed will not be broken by the
> snippet approach, since the change is opt-in.
Once a package relies on values provided by a Makefile snippe
> I think it's clearly mandatory to implement a hierarchy of settings:
>
> * Debian defaults
> * Local distribution overrides
> * Local package overrides
> * User settings
>
> where each overrides the previous ones.
I think we all mostly agree on that. I see only two remarks:
- the package can e
On Mon, Mar 16 2009, Russ Allbery wrote:
> Raphael Hertzog writes:
>
>> You're not trying very hard to look from both sides: whether the default
>> value comes from the environment or from an included Makefile, in both
>> cases the user can override it with command-line arguments.
>>
>> Granted i
On Mon, Mar 16 2009, Raphael Hertzog wrote:
> On Mon, 16 Mar 2009, Manoj Srivastava wrote:
>> > However, if the caller really wish that his build options prevail in
>> > all cases, he can use "make -e" (and dpkg-buildpackage has the -R
>> > option that let him call "debian/rules" as "make -e -f de
Raphael Hertzog writes:
> You're not trying very hard to look from both sides: whether the default
> value comes from the environment or from an included Makefile, in both
> cases the user can override it with command-line arguments.
>
> Granted it means that dpkg-buildpackage would have to pass
On Mon, Mar 16, 2009 at 09:14:32AM +0100, Raphael Hertzog wrote:
> On Sun, 15 Mar 2009, Stephen Gran wrote:
> > This one time, at band camp, Raphael Hertzog said:
> > > Care to elaborate what kind of flexibility you need in this specific case
> > > ?
> >
> > I don't. I'm imagining that some of o
On Mon, Mar 16, 2009 at 06:37:40PM +0100, Raphael Hertzog wrote:
> Suppose you have "FOO ?= bar" in the Makefile, write me the rest of the
> Makefile so that I have this:
> $ FOO=foo make
> FOO was set in the environment
> $ make FOO=foo
> FOO was set on the command-line
> $ make
> FOO was set in t
On Mon, Mar 16 2009, Raphael Hertzog wrote:
> On Mon, 16 Mar 2009, Manoj Srivastava wrote:
>> In the non-snippet method proposed, there is no way for the
>> package maintainer to override project defaults yet cater user set
>> variable settings, since the information is lost.
>
> You're
On Mon, 16 Mar 2009, Manoj Srivastava wrote:
> > However, if the caller really wish that his build options prevail in
> > all cases, he can use "make -e" (and dpkg-buildpackage has the -R
> > option that let him call "debian/rules" as "make -e -f debian/rules"
> > instead).
>
> We do not w
On Mon, 16 Mar 2009, Manoj Srivastava wrote:
> In the non-snippet method proposed, there is no way for the
> package maintainer to override project defaults yet cater user set
> variable settings, since the information is lost.
You're not trying very hard to look from both sides: whether
On Mon, Mar 16 2009, Raphael Hertzog wrote:
> On Mon, 16 Mar 2009, Bdale Garbee wrote:
>>
>> > I think he ment that you can not know wether the setting comes from
>> > dpkg-buildpackage or the user. If it comes from dpkg-buildpackage then
>> > debian/rules should be free to override it as needed.
On Mon, Mar 16 2009, Raphael Hertzog wrote:
> On Sun, 15 Mar 2009, Bill Allombert wrote:
>> There is no documented semantic for CFLAGS et. al. in Debian policy. While
>> some Makefile handle it in a certain way, this is not mandatory in
>> any way. For example some configure scripts append option
On Fri, Mar 13, 2009 at 09:04:30PM +0100, Raphael Hertzog wrote:
> * either we modify policy to mandate the set of environment variables that
> dpkg-buildpackage sets
> In terms of efforts, the first solution is the easiest. But we aim
> at the _right_ solution so feel free to design something t
Raphael Hertzog writes:
> On Fri, 13 Mar 2009, Manoj Srivastava wrote:
>> 3. dpkg-buildpackage is probably the wrong place to put this solution
>> in.
>
> Why?
>
>> The fact that dpkg-buildpackage's setting the variables is not
>> easily configurable, and presents to make as though
Raphael Hertzog wrote:
> Note that I'm not asking to mandate the tool. I would like to mandate the
> fact that packages can rely on some environment variables being set to
> some values.
Note that packages will not necessarily pickup the environment variables.
autoconf using packages will probabl
On Sun, 15 Mar 2009, Stephen Gran wrote:
> This one time, at band camp, Raphael Hertzog said:
> > Care to elaborate what kind of flexibility you need in this specific case ?
>
> I don't. I'm imagining that some of our downstreams may.
It's precisely one of our downstreams that pushed the
dpkg-bu
On Sun, 15 Mar 2009, Bill Allombert wrote:
> There is no documented semantic for CFLAGS et. al. in Debian policy. While
> some Makefile handle it in a certain way, this is not mandatory in
> any way. For example some configure scripts append options to CFLAGS while
> other will not change it if it
On Sun, Mar 15, 2009 at 05:33:31PM +0100, Raphael Hertzog wrote:
> On Fri, 13 Mar 2009, Manoj Srivastava wrote:
> > There are several things I dislike about the first option.
> > 1. I do not like that policy would turn around 15 years of convention
> > and suddenly outlaw $(MAKE) -f d
This one time, at band camp, Raphael Hertzog said:
> On Sat, 14 Mar 2009, Stephen Gran wrote:
> Note that I'm not asking to mandate the tool. I would like to mandate the
> fact that packages can rely on some environment variables being set to
> some values.
>
> > I'd be much happier with a Makefil
On Sat, 14 Mar 2009, Stephen Gran wrote:
> This one time, at band camp, Raphael Hertzog said:
> > * either we modify policy to mandate the set of environment variables that
> > dpkg-buildpackage sets
> >
[...]
> > In terms of efforts, the first solution is the easiest. But we aim at the
> > _rig
On Fri, 13 Mar 2009, Manoj Srivastava wrote:
> There are several things I dislike about the first option.
> 1. I do not like that policy would turn around 15 years of convention
> and suddenly outlaw $(MAKE) -f debian/rules foo. This will break
> many of my packages; and I do not
This one time, at band camp, Raphael Hertzog said:
> [ Bcced to -devel and -dpkg, discussion should happen on -policy ]
>
> Hello,
>
> we have an unfortunate situation where the practice in dpkg-buildpackage
> and the policy do not match fully.
>
> I tried to summarize the problem here:
> http:/
1 - 100 of 104 matches
Mail list logo
