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 |