On Mon, 2007-10-01 at 16:06 -0700, Donnie Berkholz wrote:
> On 19:16 Mon 01 Oct , Sébastien Fabbro wrote:
> > On Sun, 2007-09-30 at 13:53 -0700, Donnie Berkholz wrote:
> > > > 1.1 dev-lang/ifc/ifc-10.0.026.ebuild
> >
> > > > INSTALL_DIR=/opt/intel/${PB}${ext}/${PV}
> > > >
> > > > if use debugger && [[ ! -x /opt/intel/idb${ext}/${PV}/bin/idb
> > > > ]]; then
> > > > INSTALL_IDB_DIR=/opt/intel/idb${ext}/${PV}
> > > > else
> > > > use debugger && einfo "Debugger already installed"
> > > > rm -f data/intel*idb*.rpm
> > > > fi
> > >
> > > Could you explain what this is doing? Does some other package (icc?)
> > > also install the debugger? Perhaps it should get split off into a
> > > separate package.
> >
> > Yes, icc can install the same debugger. I thought about splitting idb in
> > another package but it would need either the ifc or the icc tar ball. I
> > thought the "or" was not supported in SRC_URI/unpack. Forcing the tar
> > ball of icc would force the ifc users to download icc one (at least
> > 40Mb) when not necessary, and vice-versa. There are probably solutions
> > to this problem, but I could not think of a simple one. Any suggestion
> > welcome.
>
> As kind of a hack solution, the idb package could have icc/ifc USE flags
> to pick which tarball it used.I have been trying to avoid the icc/ifc use flags as much as possible, in preference for things like [[ $(tc-getCC) = icc ]] but in that case it would make sense. Thanks. Sébastien
signature.asc
Description: This is a digitally signed message part
