1 |
Hi |
2 |
|
3 |
>> But not all the patches are in the portage tree? Trivial example might |
4 |
>> be the kernel where the ebuild is tiny and references an http location |
5 |
>> for the patches? |
6 |
> Then you would change the kernel ebuild in your snapshot, so that it |
7 |
> becomes self-contained. |
8 |
|
9 |
That's clearly not a practical suggestion because there are many such |
10 |
ebuilds with this behaviour and the suggestion to "rewrite all your |
11 |
ebuilds" kind of defeats the benefit of using gentoo? |
12 |
|
13 |
|
14 |
>> My understanding is that for a GPL licence one should provide a |
15 |
>> copy of these patches in the "code dump", not just an http link? |
16 |
>> Is that your understanding? |
17 |
> I think your understanding is incomplete, and I recommend that you |
18 |
> read through the license again. |
19 |
|
20 |
?? Why all the stupid hints rather than just stating the answer! |
21 |
|
22 |
Under what circumstances do you claim that it's not necessary to |
23 |
actually supply the code for a patch which has been made to a GPL |
24 |
licenced code base?? I think you are implying that it's satisfactory to |
25 |
"supply" code by having a twisted and nested chain of source locations |
26 |
for all the code, some of which may not be under my control? As you |
27 |
hint, I then have the risk of servers outside of my control causing my |
28 |
compliance failure. However, this is all moot because my whole question |
29 |
is about accurately capturing all the upstream source so that I can |
30 |
maintain my own cache? |
31 |
|
32 |
|
33 |
I'm not sure why GPL seems to attract such special behaviour. In every |
34 |
other industry one will usually provide both a legal licence and also a |
35 |
non legal "summary of intent". For some reason the open source |
36 |
advocates seem to excel in leaping on any minor misunderstanding of |
37 |
their licensing agreements, but then enjoy confounding the situation |
38 |
with "nah that's not it, but I can't give you any hints as to why I |
39 |
*think* you are wrong...". Look it's just a straightforward licence - |
40 |
we don't need to be lawyers to have a stab at complying with it and |
41 |
generally helping with understanding it's nuances... |
42 |
|
43 |
The big thing which annoys me is that one can comply with to the letter |
44 |
of the GPL with a big code dump that, and lets be honest here, benefits |
45 |
absolutely no one really (what do you do with a lump of undocumented and |
46 |
obfuscated hacky code. There are several open letters on the internet |
47 |
discussing this, but what you are looking for is people to get involved |
48 |
with the *spirit* of working within the open source process and sharing |
49 |
in a useful way, not just code dumping. |
50 |
|
51 |
The piece we are discussing here is really the boring compliance piece |
52 |
which personally I think is largely unhelpful, last chance saloon kind |
53 |
of code dump. All the useful pieces of code I try to push upstream. |
54 |
For sure the GPL provision at least means you get the code even if *I* |
55 |
don't try and push it upstream and am uncooperative, but really, for the |
56 |
vast majority of code, it's just boiler plate reproduction of stuff that |
57 |
you would get from upstream if you needed it anyway... |
58 |
|
59 |
|
60 |
>> So by implication it's not clear that catalyst does satisfy your GPL |
61 |
>> requirements for distribution? |
62 |
> I never say it did. I said that it helps with some things. |
63 |
|
64 |
What "some things"? Previously I asked for help capturing the source |
65 |
code tree and you implied that it would be correctly captured by |
66 |
catalyst - however, now it seems to be becoming clear that catalyst |
67 |
doesn't capture all the patches either? So we seem to be back to the |
68 |
original question again and catalyst seem to be just a detour that |
69 |
hasn't advanced us? |
70 |
|
71 |
With that in mind if you are using only catalyst, how do *you* make sure |
72 |
you are GPL compliant and provide all patches/sources, etc? (Not a |
73 |
challenge, just genuinely trying to learn from how others are doing things?) |
74 |
|
75 |
|
76 |
|
77 |
>> I suspect something more is probably happening, eg some of the linked |
78 |
>> patches probably get included into the source download location and |
79 |
>> probably you can pick them up there - however, there are now a LOT of |
80 |
>> ways to fetching source and patches and it would be hard to be sure |
81 |
>> of 100% coverage? |
82 |
> Fourth time: Add bookkeeping into the epatch function. |
83 |
|
84 |
No, it's not "fourth time". It was my idea in the original email! |
85 |
However, patching portage is unsatisfactory in that it's fragile and |
86 |
easily overwritten accidently. By all means if you have a way of |
87 |
patching which is less fragile, eg if there is some way to patch the |
88 |
eclass using some overlay in /usr/local/portage then I would be grateful |
89 |
for *that* information. |
90 |
|
91 |
you are just saying "do it" like having the idea is the easy bit! |
92 |
Actually the implementation seems hacky to me. Wrapping the patch |
93 |
utility seems more robust to me, but it's still not ideal... |
94 |
|
95 |
> Downloading is irrelevant, especially since sometimes many more |
96 |
> patches are downloaded than are actually applied. |
97 |
|
98 |
I'm not sure I follow? My understanding is that we need to supply |
99 |
patches that are applied, not just every patch to every ebuild - I think |
100 |
we are agreeing on that? |
101 |
|
102 |
|
103 |
> It's the other way around: |
104 |
> |
105 |
> You provide a snapshot to catalyst, and catalyst builds kernel from |
106 |
> that. You say what you want catalyst to build, and you create the |
107 |
> package. |
108 |
> |
109 |
> You may end up doing more ebuild maintenance, but you likely want to |
110 |
> do just that anyway, in order to keep track of what actually goes |
111 |
> into your system. |
112 |
|
113 |
Hmm, that's a very superficial description of what is done, but I can |
114 |
infer some of what you mean. |
115 |
|
116 |
You might be saying that you figure out every ebuild that you need in |
117 |
your solution, then manually patch them all to use source pulled down |
118 |
from your own server, plus sync all the sources from gentoo to yoru own |
119 |
server? However, this seems like a desperate amount of work? |
120 |
|
121 |
You might be saying you just snapshot the gentoo portage tree, however, |
122 |
I don't see how that helps you capture all the sources and patches |
123 |
correctly? |
124 |
|
125 |
|
126 |
Can you please clarify how you generate your portage snapshot for |
127 |
catalyst and how you create your own offline snapshot of all sources |
128 |
(including downloaded patches) - this is I think is what I'm looking to |
129 |
learn? |
130 |
|
131 |
Thanks |
132 |
|
133 |
Ed W |