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 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
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 debs.
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/and
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 Policy in
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 people
On Mon, 11 May 2009, Russ Allbery wrote:
Raphael Hertzog hert...@debian.org 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
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-buildpackage
Raphael Hertzog hert...@debian.org 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
On Mon, 11 May 2009, Russ Allbery wrote:
Raphael Hertzog hert...@debian.org 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
Raphael Hertzog hert...@debian.org 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
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,
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
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
Russ Allbery wrote:
Giacomo A. Catenazzi c...@debian.org 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.
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 cater
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 assumes
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 would you
Giacomo A. Catenazzi c...@debian.org 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
Steve Langasek vor...@debian.org 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
Raphael Hertzog hert...@debian.org 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
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 binary
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:
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 incompatibilities.
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 newish.
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 by hand
Goswin von Brederlow wrote:
Holger Levsen hol...@layer-acht.org 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
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
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 be a
Raphael Hertzog hert...@debian.org 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
Giacomo A. Catenazzi c...@debian.org 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
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
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
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 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 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 in the
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
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
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.
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 have
Steve Langasek vor...@debian.org 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'
Bill Allombert bill.allomb...@math.u-bordeaux1.fr 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
Holger Levsen hol...@layer-acht.org 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
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
On Mon, May 11, 2009 at 8:02 AM, Goswin von Brederlow goswin-...@web.de 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
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 (progressive
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.,
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'
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 cases it won't make a
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
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
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, 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:
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 all.
I
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 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 make a
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 determined that you
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 then
it would
[ 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
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 can help.
Raphael Hertzog hert...@debian.org 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 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
achieve.
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
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 Lenny,
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 widespread
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 usage.
Manoj Srivastava sriva...@debian.org 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
Raphael Hertzog hert...@debian.org 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
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 some configure
Matthias Klose d...@debian.org 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
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; but packages
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 have
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 was for
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
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 will be
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 is
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
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 probably
Raphael Hertzog hert...@debian.org 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
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
snip
In terms of efforts, the first solution is the easiest. But we aim
at the _right_ solution so feel free to design something
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 options to
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. If it
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, 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 want to override
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 not
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 the
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 our
Raphael Hertzog hert...@debian.org 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
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 debian/rules
On Mon, Mar 16 2009, Russ Allbery wrote:
Raphael Hertzog hert...@debian.org 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.
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 either
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 snippet,
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
Raphael Hertzog hert...@debian.org 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
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 cdbs
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
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
_right_
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 Makefile
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
On Fri, Mar 13 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
1 - 100 of 103 matches
Mail list logo
