| 1 |
On Sat, 7 Nov 2009, Duncan wrote: |
| 2 |
|
| 3 |
> The big combo tarball could then be restrict=mirror or whatever, with |
| 4 |
> or without a specific user click-thru (and restrict=interactive or |
| 5 |
> whatever) as necessary and already used on some packages, following |
| 6 |
> existing policies. |
| 7 |
> |
| 8 |
> Of course, there's certainly the complexity of automating the tarball |
| 9 |
> unpack of only the specific needed components, but gentoo/kde has a |
| 10 |
> **LOT** of experience with that sort of thing by now, and I'm sure |
| 11 |
> they'd be happy to share hints and helpful tactical strategies with |
| 12 |
> you, if you ask, and there's no way I can conceive it being even half |
| 13 |
> as dependency convoluted as kde4 was to figure out, so it should be |
| 14 |
> FAR easier. |
| 15 |
|
| 16 |
To make myself clearer, the tar ball includes a few binary rpms and a |
| 17 |
installer blob. Both icc and ifc tar ball include the mkl, idb and some |
| 18 |
common library rpms. If we go for a kde-split with a mirror |
| 19 |
restrict approach, users would still have to download the big (~800Mb) |
| 20 |
tar balls. Only users with use of all (icc, idb, ifc, mkl, ipp, tbb) |
| 21 |
intel software would benefit of downloading them. It is also the fact |
| 22 |
Intel has a history of changing their packaging system. Not to |
| 23 |
mention that a rpm split seems to me lot simpler to maintain and |
| 24 |
quicker to package for me than the kde-split mirror-restricted approach, |
| 25 |
and the fact my interest for these packages is limited. |
| 26 |
|
| 27 |
-- |
| 28 |
Sébastien |
Archives