FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Debian > Debian Development

 
 
LinkBack Thread Tools
 
Old 08-13-2011, 11:44 AM
Sune Vuorela
 
Default Introducing Build-Recommends / Build-Core-Depends?

On 2011-08-13, Andreas Barth <aba@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 with this proposal, I think it is
very good

/Sune


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: slrnj4cotd.p7v.nospam@sshway.ssh.pusling.com">http ://lists.debian.org/slrnj4cotd.p7v.nospam@sshway.ssh.pusling.com
 
Old 08-13-2011, 12:30 PM
Neil Williams
 
Default Introducing Build-Recommends / Build-Core-Depends?

On Sat, 13 Aug 2011 11:44:46 +0000 (UTC)
Sune Vuorela <nospam@vuorela.dk> wrote:

> On 2011-08-13, Andreas Barth <aba@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.

It's not 'that' different. Recommends currently means that the majority
of installations would be expected to need it. Build-Recommends means
that the majority of builds would be expected to need it.

Personally, I'm not sure if Build-Core-Depends is better but there does
need to be a way to list particular build-dependencies as imperative
and configurable, usually along the lines of what the
upstream ./configure type script can disable.

> (And since this is my biggest issue with this proposal, I think it is
> very good

Agreed.

I think the idea can be extended. There isn't much point in *only*
listing those packages which are directly involved in bootstrapping
cycles today, this would only cause repeated cycling through the
packages as the packages update their functional support. It would be
useful for this proposal to be adopted by many, many packages on the
basis of what can be disabled (with judicious use of the debhelper -N
option and changes in debian/rules to the ./configure or equivalent
support) as a form of future proofing.

If your (typically library) package *can* have functionality disabled,
it should be possible to use this support to build the package that way
for bootstrapping purposes, whether or not anyone is aware of a problem
in advance.

--


Neil Williams
=============
http://www.linux.codehelp.co.uk/
 
Old 08-13-2011, 01:09 PM
Charles Plessy
 
Default Introducing Build-Recommends / Build-Core-Depends?

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 annoted in an additional header (e.g.
> Build-Recommends), but are still specified in Build-Depends to not
> break the old tools.

Dear Andreas and everybody,

I think that Build-Recommends would be very useful also in the case of packages
that run regression tests with extensive dependancies. At build time, the
package could check for the availability of the recommended build dependancies,
and skip the steps that need them if they are not available. With such a
behaviour, it would not be needed to duplicate the information between the
Build-Depends and the Build-Recomends field.

The Build-Recomends field has been proposed in the past and most objections
were about reproducibility of the builds. Perhaps some policy could constraint
the use of Build-Recomends in order to avoid it to be misused.

> 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 on that this was a partial build
> and reschedule a new build when newly upcoming packages allow more
> binary packages to be built, or all build-dependencies are available
> and we could do a clean full build.

Another possibility would be to append something like “~minimal” (or shorter)
to their version number. But perhaps that would break the parsing of version
number for detecting binNMUs, if +b1~minimal would not be considered so.

> Tools
>
> This affects dpkg-buildpackage, dpkg-checkbuilddeps, and
> dpkg-gencontrol. It also (should) affect debhelper and cdbs to ease
> migration of packages to build-recommends.

mk-build-deps is inherently tolerant to missing dependancies, since it uses a
combination of equivs and apt-get -f install, but on the other hands it means
that it will not be able to allow to distinguish Build-Depends and
Build-Recommends, as apt-get -f install does not seem to install Recommends by
default.

Have a nice day,

--
Charles Plessy
Debian Med packaging team,
http://www.debian.org/devel/debian-med
Tsurumi, Kanagawa, Japan


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20110813130900.GA20385@merveille.plessy.net">http://lists.debian.org/20110813130900.GA20385@merveille.plessy.net
 
Old 08-13-2011, 01:27 PM
Colin Watson
 
Default Introducing Build-Recommends / Build-Core-Depends?

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 graphical tools). During DebConf, Wookey
> had a talk which lead to us discussing some ideas how to support that.
> Most packages are not affected at all by that, and current behaviour
> isn't changing as long as package source files are not changed.

Wookey's proposal was to have Build-Depends-Stage1 (etc. - I may have
misspelled this slightly), and for a bootstrap-aware autobuilder to
build its way through each of the stages until it reaches the real
Build-Depends. I personally prefer this approach because it makes it
clearer that the final build-depends is what we really want to reach,
and that binaries uploaded to the real Debian archive still need to have
all those build-dependencies in place.

I think Wookey indicated that there was at least one case where more
than one stage is required, in which case Build-Recommends does not
really seem to solve the full problem.

--
Colin Watson [cjwatson@debian.org]


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20110813132734.GB32525@riva.dynamic.greenend.org.u k">http://lists.debian.org/20110813132734.GB32525@riva.dynamic.greenend.org.u k
 
Old 08-13-2011, 02:04 PM
Joachim Breitner
 
Default Introducing Build-Recommends / Build-Core-Depends?

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 on that this was a partial build
> and reschedule a new build when newly upcoming packages allow more
> binary packages to be built, or all build-dependencies are available
> and we could do a clean full build.

This seems to be an unfortunate choice of a field name, as it has
different semantics than other Build-Depends fields. Why not
"Built-With:"?

Also, this might be useful independently from your feature, and in all
package, and is similar to what dh-buildinfo provides.

Greetings,
Joachim

--
Joachim "nomeata" Breitner
Debian Developer
nomeata@debian.org | ICQ# 74513189 | GPG-Keyid: 4743206C
JID: nomeata@joachim-breitner.de | http://people.debian.org/~nomeata
 
Old 08-13-2011, 02:23 PM
Andreas Barth
 
Default Introducing Build-Recommends / Build-Core-Depends?

* Colin Watson (cjwatson@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 to have the architecture
> > already available; same with graphical tools). During DebConf, Wookey
> > had a talk which lead to us discussing some ideas how to support that.
> > Most packages are not affected at all by that, and current behaviour
> > isn't changing as long as package source files are not changed.
>
> Wookey's proposal was to have Build-Depends-Stage1 (etc. - I may have
> misspelled this slightly), and for a bootstrap-aware autobuilder to
> build its way through each of the stages until it reaches the real
> Build-Depends. I personally prefer this approach because it makes it
> clearer that the final build-depends is what we really want to reach,
> and that binaries uploaded to the real Debian archive still need to have
> all those build-dependencies in place.

Wookeys proposal is less generic and more centric to bootstrapping.
Which has its advantages, and its disadvantages.

I'm not saying that this proposal is better. It is different, and has
a different set of advantages. Plusside is that it's more generic, so
you could do more with debian/control fields, debhelper and cdbs, and
less with specific additions to debian/rules.

Generic options are usually better IMHO, but well - YMMV.



> I think Wookey indicated that there was at least one case where more
> than one stage is required, in which case Build-Recommends does not
> really seem to solve the full problem.


As long as all stages produces binary packages which are policy
conformant working, it does.

Consider this case:
Source: A
Build-Depends: b, c
Build-Core-Depends:
Binary: a1
Binary: a2, build-depends b
Binary: a3, build-depends c

Source: B
Build-Depends: a1
Binary: b

Source: C
Build-Depends: a2
Binary: c


In this case, the first run on A will only produce a1. Then B could be
built, then re-build A with what is available now. This will produce
a1 and a2. Then build C. Then re-build A with all Build-Depends
installed, which will give us a full package set.





Andi


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20110813142328.GU15003@mails.so.argh.org">http://lists.debian.org/20110813142328.GU15003@mails.so.argh.org
 
Old 08-13-2011, 02:26 PM
Andreas Barth
 
Default Introducing Build-Recommends / Build-Core-Depends?

* Joachim Breitner (nomeata@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: minmal package_version ....
> > injected, so that one could see later on that this was a partial build
> > and reschedule a new build when newly upcoming packages allow more
> > binary packages to be built, or all build-dependencies are available
> > and we could do a clean full build.
>
> This seems to be an unfortunate choice of a field name, as it has
> different semantics than other Build-Depends fields. Why not
> "Built-With:"?

As said - names are just names now, and I assume them to change till
implementation. (But if, I think "Build-With" is better.)

> Also, this might be useful independently from your feature, and in all
> package, and is similar to what dh-buildinfo provides.

My proposal isn't restricted to the package required to bootstrapping.
However, if they make bootstrapping way easier, that's the use case
why we should invest the effort. I see more usage in other areas than
only bootstrapping; that's the reason why I tried to make it a bit
more generic.



Andi


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20110813142636.GV15003@mails.so.argh.org">http://lists.debian.org/20110813142636.GV15003@mails.so.argh.org
 
Old 08-13-2011, 02:48 PM
Guillem Jover
 
Default Introducing Build-Recommends / Build-Core-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 graphical tools). During DebConf, Wookey
> had a talk which lead to us discussing some ideas how to support that.
> Most packages are not affected at all by that, and current behaviour
> isn't changing as long as package source files are not changed.
>
> Below is my summary of the ideas - names et all are of course just
> names and up to be changed. Advantage of this schema is that most
> implementation is just package-local - the maintainer knows which
> minimal versions his source package could produce, and just annotates
> them. Coordination between different packages is not needed so much
> anymore, and we could try to bring the build-dependencies more into a
> tree-shape. Please see e.g.
> http://meetings-archive.debian.net/pub/debian-meetings/2011/debconf11/low/745_Bootstrapable_Debian.ogv
> for the talk.

During the Extremadura Embedded meeting in 2006 we discussed too these
things, and I came up with the following proposals, which should be
generic enough not only for bootstrapping but also for embedded type
of reduced builds:

<http://www.hadrons.org/~guillem/debian/docs/embedded.proposal>

regards,
guillem


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20110813144839.GA5708@gaara.hadrons.org">http://lists.debian.org/20110813144839.GA5708@gaara.hadrons.org
 
Old 08-13-2011, 03:09 PM
Henrique de Moraes Holschuh
 
Default Introducing Build-Recommends / Build-Core-Depends?

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 copyright), and that it might be that not all
> binary packages are built (e.g. via the Build-Dependency-mechanimsn in
> debian/control above). Often cutting off documentation and graphical
> packages is enough for a minimal version.
>
> 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 on that this was a partial build
> and reschedule a new build when newly upcoming packages allow more
> binary packages to be built, or all build-dependencies are available
> and we could do a clean full build.

The resulting packages MUST NOT lack any files or symbols/modules that
would be noticed by packages that depend on it. Otherwise, we might
have unexpected (and untracked!) partial functionality down the
dependecy graph.

Alternatively, we can annotate all packages that depend on this one for
rebuilding. This is entirely doable, but it may require an extremely
large number of rebuilds (entire trees might need to be rebuilt a number
of times) even if you do intelligent partitioning of the rebuild set.

I actually prefer the second alternative, because it is entirely
non-trivial to know that you're missing a symbol or file that could be
used by some other package (especially if such packages do something
weird).

--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20110813150941.GA32679@khazad-dum.debian.net">http://lists.debian.org/20110813150941.GA32679@khazad-dum.debian.net
 
Old 08-13-2011, 03:15 PM
Neil Williams
 
Default Introducing Build-Recommends / Build-Core-Depends?

On Sat, 13 Aug 2011 16:48:39 +0200
Guillem Jover <guillem@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 utilities means you need to have the architecture
> > already available; same with graphical tools). During DebConf, Wookey
> > had a talk which lead to us discussing some ideas how to support that.
> > Most packages are not affected at all by that, and current behaviour
> > isn't changing as long as package source files are not changed.
> >
> > Below is my summary of the ideas - names et all are of course just
> > names and up to be changed. Advantage of this schema is that most
> > implementation is just package-local - the maintainer knows which
> > minimal versions his source package could produce, and just annotates
> > them. Coordination between different packages is not needed so much
> > anymore, and we could try to bring the build-dependencies more into a
> > tree-shape. Please see e.g.
> > http://meetings-archive.debian.net/pub/debian-meetings/2011/debconf11/low/745_Bootstrapable_Debian.ogv
> > for the talk.
>
> During the Extremadura Embedded meeting in 2006 we discussed too these
> things, and I came up with the following proposals, which should be
> generic enough not only for bootstrapping but also for embedded type
> of reduced builds:
>
> <http://www.hadrons.org/~guillem/debian/docs/embedded.proposal>

Sounds like we need an Emdebian / FTP / Dpkg sprint in 2011/2012 to
finally decide on one of the many ideas, get it *implemented* and stop
going around the same loop with different names but the same objective.

There's nothing intrinsically wrong with the 2006 proposal, just like
there isn't that much wrong with Wookey's DebConf11 proposal and
Andreas' current nomenclature in this thread.

Can we please stop discussing / painting the bike shed, get together and
fix this for Wheezy? It's an ideal time when so many libraries are
being refreshed for MultiArch and the revolution in cross-building
which MultiArch itself can provide.

(Note: there won't be any point in a sprint unless Guillem & Raphael
are able to attend and this would also give a chance to sort out the
TDeb stalemate at the same time.)

Guillem - at DebConf11, our DPL pushed for more sprints. All that's
needed is the date of a long weekend which you and Raphael can be in
the same place. The venue will presumably be somewhere in France /
western Europe. Steve McIntyre & Neil McGovern stepped forward to
organise the event itself.

All the team need is a date when you, Guillem, & Raphael are both
available.

Just don't schedule it over the weekend of Steve McIntyre's wedding
(Sept 10th) or I will be in BIG trouble.
;-)

(Something in late October / November this year anyone?)

It'll be REALLY disappointing if this thread just results in yet more
discussion over semantics and nomenclature.

Debian is a do-ocracy, so 6 years of discussion really needs to end with
something actually being done.

--


Neil Williams
=============
http://www.linux.codehelp.co.uk/
 

Thread Tools




All times are GMT. The time now is 04:48 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org