On Sun, Dec 18, 2005 at 01:30:56PM +0100, Lars Nordlund wrote:
> On Sun, 18 Dec 2005 12:09:13 +0100 (CET)
> Dieter Baron <dillo@danbala.ifoer.tuwien.ac.at> wrote:
> > : The ${ORDERFILE} shall be used to generate a dummy meta-pkg. I suppose
> > : it contains a list of strings on this format 'lang/erlang' ? If so, it
> > : should be easy.
> > 
> >   This approach does not work: the bulk build builds conflicting
> > packages, so you cannot have a meta-package that depends on all of
> > them.  Besides, that is a big waste of disk space, since you require
> > all of them to be installed.  Also, one of the benefits of the bulk
> > build framework is that exactly the dependencies of a package are
> > installed during it's build.
> 
> How do you mean conflicting packages? Ah, you mean for example the same
> package but with different options set? Or wm/fvwm2 and wm/fvwm-devel?
> Well, perhaps options are not implemented just yet?

  I mean wm/fvwm2 and wm/fvwm-devel.

> About disk space: The bulk machines would have to buy bigger
> harddrives, yes. I do not see a way to deinstall packages during the
> build when other processes/machines may have them buildlinked from
> their work directories.

  When spread across multiple machines, I assumed only pkgsrc and
binary packages are shared, with each machine having its own
localbase.  Sharing one localsource across multiple parallel builds
conflicts with the current bulk build mechanism.

> How much space does it take to have all 5000 or so packages installed
> at the same time?

  (A) It doesn't work (due to conflicting packages), (b) it adds risk
to random, unwanted interference between installed packages and
package builds, and (c) it is unreasonable to waste that much disk
space.  But due to (a), this whole part of the discussion is moot.

> >   We will have to do the task scheduling ourselves.
> 
> Please explain. Do yourself, what make(1) already do today?

  More or less.  We may be able to use make for (part of) this, if we
have a target that (a) deinstalls all packages that are not
dependencies of the package to be built, (b) installs all
dependencies, (c) builds the package.

> Or are you perhaps hinting against the interesting problem we will be
> facing:
> 
> "find the biggest set of non-conflicting packages that has not already
> been built"  :-)

  I think simly handing out the first package from the list for which
all dependencies are available will be enough, at least for the first
version.

> Making full use of 'parallel' in 'bulk' will be really hard to do. A bit
> unfortunate, since the more packages are involved in a single
> invocation of make, the better.

						yours,
						dillo