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
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
n a huff if we go that direction or anything. :) But I do
>> want to be sure that we're all clear on what we're saying if we do take
>> that approach and make dpkg-buildpackage the only supported way to build
>> packages. I think it's likely that if we go that rou
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
the packaging format, so clearly that answer is yes insofar
as you think the current Debian archive is sensible. dpkg-buildpackage
setting CFLAGS is a recent change.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
--
To UNSUBSCRIBE, email to debian-devel-r
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
hat we're all clear on what we're saying if we do take
> that approach and make dpkg-buildpackage the only supported way to build
> packages. I think it's likely that if we go that route, with it
> providing the defaults, we'll find over time that some packages will
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
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 way (without need to remember a lot of details). I think
also that most of DD
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
>
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
> becau
> 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 way (without need to remember a lot of details)
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-buildpack
o cater to end
users building, tweaking, and rebuilding our software.
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 way (wi
. git-buildpackage, svn-buildpackage,
... or even dpkg-buildpackage could do this too.
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:
I see that a lot of my sponsoree forgot to check *carefully* logs,
to loo
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
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
&g
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
the benefits of these distro build flags?
>
> I hadn't considered that possibility, because I can't imagine anyone
> wanting to build packages that way instead of using dpkg-buildpackage,
> which does it all in a single command. So I really don't consider that an
>
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
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.
If the behaviour of the package is substantively different when
we use or not use dpkg-buildpackage, it would be a cl
things is a given, and a separate issue.
> Another negative aspect of the include approach is the lack of
> tracability. Right now when the user overrides a build flag it appears
> in the build log since dpkg-buildpackage prints it out in the log:
> dpkg-buildpackage: use CFLAGS from environme
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-
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,
> ...
hanges file and have DAK forward it to
buildd.debian.org for archival. git-buildpackage, svn-buildpackage,
... or even dpkg-buildpackage could do this too.
MfG
Goswin
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
but that's
>> > basically
>> > what we have here.
>
> I have sympathy for Steve viewpoint however it lacks an alternative proposal.
>
> However I cannot only strongly disagree with Raphael argument below:
>
>> Another negative aspect of the include appro
r's 'include' functionality, but that's
>> > basically what we have here.
>
>> Guillem pointed out one problem: Either you do it via a make include (which
>> you have issues with), or you stop supporting calling debian/rules directly
>> (inconvenie
y, but that's
> > basically what we have here.
> Guillem pointed out one problem: Either you do it via a make include (which
> you have issues with), or you stop supporting calling debian/rules directly
> (inconvenient, probably prone to break things)
I don't agree that
kage
> to handle it itself (unreliable, stupid) -- or you have the current
> situation,
> which is somewhere in the middle. For example, you possibly get something
> different depending on whether you call debian/rules, dpkg-buildpackage,
> debuild, or pbuilder. And the diffe
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
e in the middle. For example, you possibly get something
different depending on whether you call debian/rules, dpkg-buildpackage,
debuild, or pbuilder. And the difference is hard to explain or analyze.
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "
ever it lacks an alternative proposal.
However I cannot only strongly disagree with Raphael argument below:
> Another negative aspect of the include approach is the lack of
> tracability. Right now when the user overrides a build flag it appears
> in the build log since dpkg-buildpackage
o implement config
> files using your interpreter's 'include' functionality, but that's basically
> what we have here.
Another negative aspect of the include approach is the lack of
tracability. Right now when the user overrides a build flag it appears
in the build log si
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; plea
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:
iable names
upstream may be using, otherwise you'd add new problems while adding new vars.
>
>
> So I think for next dpkg upload we should make dpkg-buildpackage stop
> setting any flags by default, and switch the setting to go through the
Please do so!
+1 from m
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 uploa
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
On Wed, Apr 22, 2009 at 10:32:27AM +0200, Raffaele Morelli wrote:
> Just did it on another machine with libgdal1-1.5, but I need this support
> for libgdal1-1.4* on another one.
> Does gdal-ecw plugin works for previous gdal releases?
>
No, you need to change a bit patches for that,
and anyway if
turned error code 512
> > make[1]: *** [binary-common] Error 1
> > make[1]: Leaving directory `/home/morelli/gdal-1.4.4'
> > make: *** [binary-arch] Error 2
> > dpkg-buildpackage: failure: debian/rules binary gave error exit status 2
> >
> > libNCSUtil.so.0 is p
for
> /usr/local/lib/libNCSUtil.so.0 (used by
> debian/libgdal1-1.4.0/usr/lib/libgdal1.4.0.so.1.11.4).
> dh_shlibdeps: command returned error code 512
> make[1]: *** [binary-common] Error 1
> make[1]: Leaving directory `/home/morelli/gdal-1.4.4'
> make: *** [binary-arch] Error 2
>
inary-common] Error 1
make[1]: Leaving directory `/home/morelli/gdal-1.4.4'
make: *** [binary-arch] Error 2
dpkg-buildpackage: failure: debian/rules binary gave error exit status 2
libNCSUtil.so.0 is part of libecw and lives in /usr/local/
I tried using the -d flag with dpkg-buildpackage
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
ncern was over packages
starting to rely on this behavior of dpkg-buildpackage, thus making it
difficult to use a different solution.
At the time, I didn't think of the makefile fragment idea that Manoj has
proposed. If I had thought of that, I would have pushed that, since I
think it addresses the
explicit setting of CFLAGS. I know nearly all of mine (that care about
CFLAGS at all) are. The main exception are Perl modules, for which I've
mostly switched to debhelper v7 rule minimization.
When this change was originally made in dpkg-buildpackage, it broke
several packages that didn&#x
is in
> > more widespread usage.
>
> For ten years, the "common practice" was that dpkg-buildpackage did not set
> any variable.
It does set the dpkg-architecture related variables since 2001, so that's
not true.
> We cannot standardize on the "env variable pr
e proposal is in
> > more widespread usage.
>
> 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
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. I
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, and should be
fixed ASAP. Now we have packages that do not build correctly wit
you really care about being able
> to call debian/rules directly you can always adapt your rules files
> accordingly like I suggested at the end of this mail:
> http://lists.debian.org/debian-devel/2009/03/msg00920.html
> We could even write such a Makefile that mimics more closely what
&
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.
>>
>>
> out different
If the policy document the fact that the rules files need some input
variables, then it's not a big deal: if you really care about being able
to call debian/rules directly you can always adapt your rules files
accordingly like I suggested at the end of this mail:
http://li
our debian/rules, which will be a PITA to
> achieve.
Modulo debhelper, cdbs, et.al can help.
> AFAIU Raphael's proposal, the site-specific configuration will be
> achieved via dpkg-buildpackage config's file, without needing to
> include anything explicitly in
oposal, the site-specific configuration
will be achieved via dpkg-buildpackage config's file, without needing
to include anything explicitly in debian/rules, while you are
insisting in the explicit include.
While I understand (though I disagree) with your reasons for having
that include, t
; Who said the command line was for site-specific stuff?
>
> In my proposition the hierarchy could be something like this:
> - distribution default (encoded in dpkg-buildpackage or in a
> /etc/dpkg/origins/ file)
The latter is better, since it does not force people to
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;
only require a
binNMU once cdbs includes that file on its own.
IMO this is what looks like The Right Solution; are we willing to ignore it
just because it would take some time?
Anyway, any package that was last updated before dpkg-buildpackage started
to set the environment vars could easily be disc
propriate variable on the make command line
with, for example:
make -f debian/rules CFLAGS=blah
Not in Policy: dpkg-buildpackage could certainly have a useful option for
doing the last, and I think that would be a worthwhile feature.
> It would be nice to have figures here.
I don't ha
ition the hierarchy could be something like this:
- distribution default (encoded in dpkg-buildpackage or in a /etc/dpkg/origins/
file)
- site-specific (/etc/dpkg/dpkg-buildpackage.conf)
- package specific (inside debian/rules)
- user specific (command line options)
In my opinion, the origin of the
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
line arguments.
>>
>> Granted it means that dpkg-buildpackage would have to pass
>> user-overriden flags on the command line instead of using the
>> environment, but that can be done if people really want this
>> possibility.
>
> I think it's clearly mandatory
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 le
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-buildpackag
t; I don't. I'm imagining that some of our downstreams may.
>
> It's precisely one of our downstreams that pushed the
> dpkg-buildpackage change (Ubuntu). I don't think most downstreams
> care a lot about the exact implementation, but they clearly want
> a way to
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
n is lost.
>
> 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 woul
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/
rom 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 user-overriden
flags on the command line instead of using the environment, but th
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 sho
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 desi
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
>> easi
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 do
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
variables are set to specific values when we call debian/rules
> won't break packages.
> (It did break some packages when dpkg-buildpackage started setting those
> variables (in the lenny cycle) but they have all been fixed now.)
You are conflating breakage that were reported with br
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
201 - 300 of 432 matches
Mail list logo
