| 1 |
Sébastien Fabbro posted on Fri, 06 Nov 2009 16:04:41 -0800 as excerpted: |
| 2 |
|
| 3 |
> We have a few fetch restricted Intel packages in the main tree (icc, |
| 4 |
> ifc, mkl, ipp, tbb). All except tbb are closed-source but free with |
| 5 |
> non-commercial licenses. Lately upstream has repackaged the icc and |
| 6 |
> ifort (ifc) as a big tar blob containing all of them, but also release |
| 7 |
> some of them separately. For various reasons we would like to keep |
| 8 |
> separate ebuilds. The problem is the separate packages have common |
| 9 |
> libraries, causing duplication and file collisions. So the idea was to |
| 10 |
> download the tar blob which contain a few binary rpms and base new |
| 11 |
> ebuilds on these rpms. |
| 12 |
|
| 13 |
To here looks reasonable... |
| 14 |
|
| 15 |
> This means we will have to re-distribute the rpms on our mirrors. |
| 16 |
|
| 17 |
This conclusion doesn't necessarily follow from the above, unless you |
| 18 |
summarized-out the important technical issues. See below. |
| 19 |
|
| 20 |
> I can't understand from the many licenses if we are |
| 21 |
> allowed to do it, it surprisingly looks like we can do it. |
| 22 |
|
| 23 |
No position on the legal aspect, except that if we can avoid the question |
| 24 |
by not distributing them at all, much as we do with various other |
| 25 |
restrict=mirror packages, that would seem to me to be the way to go. |
| 26 |
|
| 27 |
What I'm missing is why a combination of the approach used for, say, the |
| 28 |
kde split ebuilds, and the standard restrict=mirror ebuilds, can't be |
| 29 |
used. It seems to me that the ebuilds could each require the big combo- |
| 30 |
tarball, extract only the necessary component rpms, and go from there, |
| 31 |
much as the kde split ebuilds do with the big combo tarballs that kde |
| 32 |
ships except they don't have the rpms step to worry about and I expect |
| 33 |
the kde interdependencies were far more complex to try to work out (you'd |
| 34 |
need to ask the gentoo/kde folks on that to be sure, but from a user who |
| 35 |
followed the experimentals to some degree, that certainly seems to be the |
| 36 |
case). |
| 37 |
|
| 38 |
The big combo tarball could then be restrict=mirror or whatever, with or |
| 39 |
without a specific user click-thru (and restrict=interactive or whatever) |
| 40 |
as necessary and already used on some packages, following existing |
| 41 |
policies. |
| 42 |
|
| 43 |
Of course, there's certainly the complexity of automating the tarball |
| 44 |
unpack of only the specific needed components, but gentoo/kde has a |
| 45 |
**LOT** of experience with that sort of thing by now, and I'm sure they'd |
| 46 |
be happy to share hints and helpful tactical strategies with you, if you |
| 47 |
ask, and there's no way I can conceive it being even half as dependency |
| 48 |
convoluted as kde4 was to figure out, so it should be FAR easier. |
| 49 |
|
| 50 |
-- |
| 51 |
Duncan - List replies preferred. No HTML msgs. |
| 52 |
"Every nonfree program has a lord, a master -- |
| 53 |
and if you use the program, he is your master." Richard Stallman |
Archives