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
