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
