Kyle Willmon writes (Re: Introducing Build-Recommends / Build-Core-Depends?):
So, if you think it's ok to leave out the words Depends and
Recommends, the logical idea would be to use Build-Stage1 (though I
do not think this is the correct route. I, personally, am in favor of
Build-Depends
Hi there,
On Sat, Aug 13, 2011 at 01:28:36PM +0200, Andreas Barth wrote:
Introducing Build-Recommends / Build-Core-Depends
We should be able to specify in the package saying only these
build-dependencies are needed to get a functionally working package.
For such an build, the packages which
On Mon, Sep 12, 2011 at 03:36:46PM +0100, Steve Langasek wrote:
On Sat, Aug 13, 2011 at 01:28:36PM +0200, Andreas Barth wrote:
Introducing Build-Recommends / Build-Core-Depends
Build-Recommends is a bad name for this for two reasons:
[...]
So Build-Core-Depends would certainly be a better
On Mon, Sep 12, 2011 at 10:57:10PM +0200, Adam Borowski wrote:
On Mon, Sep 12, 2011 at 03:36:46PM +0100, Steve Langasek wrote:
So Build-Core-Depends would certainly be a better approach, but I wonder why
this isn't being called Build-Depends-Stage1 or similar?
What about Build-Minimal?
On Sun, 14 Aug 2011 17:54:55 -0500
Peter Samuelson pe...@p12n.org wrote:
[Andreas Barth]
Introducing Build-Recommends / Build-Core-Depends
We should be able to specify in the package saying only these
build-dependencies are needed to get a functionally working package
Eugene V. Lyubimkin wrote:
If we accept the idea there's now more than one way to build the
package, I would like us do not limit the number of ways to '2' but
rather extend the prospoal to set up something similar to Gentoo's USE
flags. The advantages of that idea:
- porters/buildds/local
Andreas Barth wrote:
* Colin Watson (cjwat...@debian.org) [110813 15:27]:
On Sat, Aug 13, 2011 at 01:28:36PM +0200, Andreas Barth wrote:
During bootstraping a new architecture, there are sometimes ugly
build-dependency-loops (usually involving generating documentation
for the core build
* Andreas Barth [2011-08-13 13:28 +0200]:
Also, the binary packages in the debian/control template could have
Build-Depends specified which means that they should only be built if
those packages are actually installed ...
An optional Build-Depends: field per binary package as you described
is
* Steve McIntyre (st...@einval.com) [110815 12:27]:
Eugene V. Lyubimkin wrote:
Source: fbreader
Build-Depends-Core: debhelper (= 7), libbz2-dev
Build-Depends-Qt3: libqt3-mt-dev
Build-Depends-Qt4: libqt4-dev
Build-Depends-Gtk2: libgtk2.0-dev
I can see this turning into a large mess. What's
* Steve McIntyre (st...@einval.com) [110815 12:30]:
Andreas Barth wrote:
Generic options are usually better IMHO, but well - YMMV.
Often, yes. But also often at extra cost.
No doubt about that.
Where is the added benefit
here - i.e. what are the use cases?
I'm not sure I could speak
* Steve McIntyre [2011-08-15 11:12 +0100]:
Andreas Barth wrote:
Generic options are usually better IMHO, but well - YMMV.
Often, yes. But also often at extra cost. Where is the added benefit
here - i.e. what are the use cases? I'm 100% behind making the
bootstrap phase more simple, but I
* Carsten Hey (cars...@debian.org) [110815 13:36]:
An optional Build-Depends: field per binary package as you described
is essentially the same as the following, with the notable difference,
that the below could appear as it is in the output of, i.e., apt-cache
showsrc without requiring
* Andreas Barth [2011-08-15 13:46 +0200]:
* Carsten Hey (cars...@debian.org) [110815 13:36]:
An optional Build-Depends: field per binary package as you described
is essentially the same as the following, with the notable difference,
that the below could appear as it is in the output of,
* Carsten Hey (cars...@debian.org) [110815 14:36]:
* Andreas Barth [2011-08-15 13:46 +0200]:
* Carsten Hey (cars...@debian.org) [110815 13:36]:
An optional Build-Depends: field per binary package as you described
is essentially the same as the following, with the notable difference,
On Mon, Aug 15, 2011 at 13:42:20 +0200, Andreas Barth wrote:
I'm not sure I could speak about cases, but an obvious use case
aside from bootstrapping is backporting, where I could just drop off
dependencies I'm not going to use instead of looking at the code and
figuring out if it's easier to
Andreas Barth wrote:
Also, the binary packages in the debian/control template could have
Build-Depends specified which means that they should only be built if
those packages are actually installed (so we could do an automated
graph analyis, and also dh and cdbs could just drop them, so that
* Joey Hess (jo...@debian.org) [110815 18:32]:
Andreas Barth wrote:
Also, the binary packages in the debian/control template could have
Build-Depends specified which means that they should only be built if
those packages are actually installed (so we could do an automated
graph analyis,
Le Mon, Aug 15, 2011 at 11:12:36AM +0100, Steve McIntyre a écrit :
Andreas Barth wrote:
Generic options are usually better IMHO, but well - YMMV.
Often, yes. But also often at extra cost. Where is the added benefit
here - i.e. what are the use cases? I'm 100% behind making the
bootstrap
[Andreas Barth]
Introducing Build-Recommends / Build-Core-Depends
We should be able to specify in the package saying only these
build-dependencies are needed to get a functionally working package.
For such an build, the packages which are not needed for building
working core packages
rid of the
build-dependency-loops as far as technically possible. Upstream is
usually better than we are by using ./configure and scaning which
packages are there, and which not, whereas we usually depend on the
full archive being already built.
Introducing Build-Recommends / Build-Core-Depends
On 2011-08-13, Andreas Barth a...@not.so.argh.org wrote:
Introducing Build-Recommends / Build-Core-Depends
I like making it easier to bootstrap new architectures, but I don't like
overloading the 'recommends' word with a partly different meaning.
(And since this is my biggest issue
On Sat, 13 Aug 2011 11:44:46 + (UTC)
Sune Vuorela nos...@vuorela.dk wrote:
On 2011-08-13, Andreas Barth a...@not.so.argh.org wrote:
Introducing Build-Recommends / Build-Core-Depends
I like making it easier to bootstrap new architectures, but I don't like
overloading the 'recommends
On 2011-08-13 13:28, Andreas Barth wrote:
Building with core Dependencies only
If doing an build of the core functionality only, norecommends is
added to the environment DEB_BUILD_OPTIONS. This is the signal for
dpkg-buildpackage etc to only check for the minimal set of packages,
and for
Le Sat, Aug 13, 2011 at 01:28:36PM +0200, Andreas Barth a écrit :
We should be able to specify in the package saying only these
build-dependencies are needed to get a functionally working package.
For such an build, the packages which are not needed for building
working core packages are
On Sat, Aug 13, 2011 at 01:28:36PM +0200, Andreas Barth wrote:
During bootstraping a new architecture, there are sometimes ugly
build-dependency-loops (usually involving generating documentation
for the core build utilities means you need to have the architecture
already available; same with
Hi,
just a minor note:
Am Samstag, den 13.08.2011, 13:28 +0200 schrieb Andreas Barth:
To mark such packages and to be able to decide when to re-schedule the
build, all binary-packages get the additional header
Build-Depends: minmal package_version
injected, so that one could see later
* Eugene V. Lyubimkin (jac...@debian.org) [110813 14:58]:
On 2011-08-13 13:28, Andreas Barth wrote:
Building with core Dependencies only
If doing an build of the core functionality only, norecommends is
added to the environment DEB_BUILD_OPTIONS. This is the signal for
* Colin Watson (cjwat...@debian.org) [110813 15:27]:
On Sat, Aug 13, 2011 at 01:28:36PM +0200, Andreas Barth wrote:
During bootstraping a new architecture, there are sometimes ugly
build-dependency-loops (usually involving generating documentation
for the core build utilities means you need
* Joachim Breitner (nome...@debian.org) [110813 16:05]:
Hi,
just a minor note:
Am Samstag, den 13.08.2011, 13:28 +0200 schrieb Andreas Barth:
To mark such packages and to be able to decide when to re-schedule the
build, all binary-packages get the additional header
Build-Depends:
Hi!
On Sat, 2011-08-13 at 13:28:36 +0200, Andreas Barth wrote:
During bootstraping a new architecture, there are sometimes ugly
build-dependency-loops (usually involving generating documentation
for the core build utilities means you need to have the architecture
already available; same with
On Sat, 13 Aug 2011, Andreas Barth wrote:
Resulting packages
All binary packages built need to be functionally working, and follow
the standard for packages on ftp-master. This means they could e.g.
miss documentation (as long as they are not RC-buggy, i.e. they need
to have changelog and
On Sat, 13 Aug 2011 16:48:39 +0200
Guillem Jover guil...@debian.org wrote:
On Sat, 2011-08-13 at 13:28:36 +0200, Andreas Barth wrote:
During bootstraping a new architecture, there are sometimes ugly
build-dependency-loops (usually involving generating documentation
for the core build
32 matches
Mail list logo
