On Sat, 7 Nov 2009, Duncan wrote:

> The big combo tarball could then be restrict=mirror or whatever, with
> or without a specific user click-thru (and restrict=interactive or
> whatever) as necessary and already used on some packages, following
> existing policies.
> 
> Of course, there's certainly the complexity of automating the tarball 
> unpack of only the specific needed components, but gentoo/kde has a 
> **LOT** of experience with that sort of thing by now, and I'm sure
> they'd be happy to share hints and helpful tactical strategies with
> you, if you ask, and there's no way I can conceive it being even half
> as dependency convoluted as kde4 was to figure out, so it should be
> FAR easier.

To make myself clearer, the tar ball includes a few binary rpms and a
installer blob. Both icc and ifc tar ball include the mkl, idb and some
common library rpms. If we go for a kde-split with a mirror
restrict approach, users would still have to download the big (~800Mb)
tar balls. Only users with use of all (icc, idb, ifc, mkl, ipp, tbb)
intel software would benefit of downloading them. It is also the fact
Intel has a history of changing their packaging system. Not to
mention that a rpm split seems to me lot simpler to maintain and
quicker to package for me than the kde-split mirror-restricted approach,
and the fact my interest for these packages is limited.

--
Sébastien