Sébastien Fabbro posted on Fri, 06 Nov 2009 16:04:41 -0800 as excerpted:

> We have a few fetch restricted Intel packages in the main tree (icc,
> ifc, mkl, ipp, tbb). All except tbb are closed-source but free with
> non-commercial licenses. Lately upstream has repackaged the icc and
> ifort (ifc) as a big tar blob containing all of them, but also release
> some of them separately. For various reasons we would like to keep
> separate ebuilds. The problem is the separate packages have common
> libraries, causing duplication and file collisions. So the idea was to
> download the tar blob which contain a few binary rpms and base new
> ebuilds on these rpms.

To here looks reasonable...

> This means we will have to re-distribute the rpms on our mirrors.

This conclusion doesn't necessarily follow from the above, unless you 
summarized-out the important technical issues.  See below.

> I can't understand from the many licenses if we are
> allowed to do it, it surprisingly looks like we can do it.

No position on the legal aspect, except that if we can avoid the question 
by not distributing them at all, much as we do with various other 
restrict=mirror packages, that would seem to me to be the way to go.

What I'm missing is why a combination of the approach used for, say, the 
kde split ebuilds, and the standard restrict=mirror ebuilds, can't be 
used.  It seems to me that the ebuilds could each require the big combo-
tarball, extract only the necessary component rpms, and go from there, 
much as the kde split ebuilds do with the big combo tarballs that kde 
ships except they don't have the rpms step to worry about and I expect 
the kde interdependencies were far more complex to try to work out (you'd 
need to ask the gentoo/kde folks on that to be sure, but from a user who 
followed the experimentals to some degree, that certainly seems to be the 
case).

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.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman