Subject: Re: Alternatives system, 2nd round
To: Todd Vierling <tv@duh.org>
From: Julio M. Merino Vidal <jmmv84@gmail.com>
List: tech-pkg
Date: 01/21/2005 21:09:53
On Fri, 2005-01-21 at 14:51 -0500, Todd Vierling wrote:
> On Fri, 21 Jan 2005, Julio M. Merino Vidal wrote:

> > - I have to add a way so that bulk builds do not generate any of the
> >   wrappers.  Why?  Suppose you install a single python implementation
> >   and the 'python' wrapper is generated.  Then, while building other
> >   packages, it might happen that they find the wrapper instead of the
> >   real program (thus causing inconsistencies - expecting one version
> >   but finding a different one - during the build).
> 
> Bulk builds remove non-dependency packages with pkg_delete before building
> each package.  So, as long as pkg_delete can do something useful, or the
> fallback logic works correctly, all should be fine.

I was thinking on the following situation: suppose you have A which
depends on B and C.  B depends on python 2.2 while C depends on python
2.3 (dunno if this may happen in pkgsrc atm).

The bulk build installs B as a prereq, and the python wrapper ends up
pointing to python 2.2.  Then it installs C but the wrapper is not
modified.

At last, it starts configuring A, which also requires python.  Two
situations possible:

1) A requires python (say 2.3): in such case, it might happen that it
   first tries to look for the "python" name and then for "python2.3".
   Humm, it will pick up python (which was pointing to 2.2).  There
   you have a problem.

   Ooh, well, these are real bugs in the configuration scripts WRT
   pkgsrc...

2) A does not require python, but it has optional support.  Then it
   looks like for 'python' presence and finds the wrapper.  Oops,
   another problem.

   Yeah, that's another bug in the package, because it should be
   disabling python explicitly...

> And we certainly want binpkgs generated by bulk builds to generate
> alternatives on pkg_add.  8-)

Yes, of course.  I was just thinking about a way to tell the INSTALL
scripts to not do the alternatives stuff.  They'd still be built in
them, but you'd have a chance to disable its installation (just like
the PKG_RCD_SCRIPTS variable and such).

But maybe what I said above are not real problems (and they may even
let us catch real bugs, heh!).

Cheers,

-- 
Julio M. Merino Vidal <jmmv84@gmail.com>
http://www.livejournal.com/users/jmmv/
The NetBSD Project - http://www.NetBSD.org/