<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">2017-09-28 11:02 GMT-07:00 Daniel Berlin <span dir="ltr"><<a href="mailto:dberlin@dberlin.org" target="_blank">dberlin@dberlin.org</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><br></div><div class="gmail_extra"><br><div class="gmail_quote"><div><div class="h5">On Thu, Sep 28, 2017 at 10:57 AM, Mehdi AMINI <span dir="ltr"><<a href="mailto:joker.eph@gmail.com" target="_blank">joker.eph@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><div class="m_-3476773333820703913gmail-h5"><br><div class="gmail_extra"><br><div class="gmail_quote">2017-09-28 10:37 GMT-07:00 Daniel Berlin <span dir="ltr"><<a href="mailto:dberlin@dberlin.org" target="_blank">dberlin@dberlin.org</a>></span>:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote"><span>On Thu, Sep 28, 2017 at 9:46 AM, Mehdi AMINI <span dir="ltr"><<a href="mailto:joker.eph@gmail.com" target="_blank">joker.eph@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote"><div><div class="m_-3476773333820703913gmail-m_5456984594455962221m_-6889126931737582998h5">2017-09-28 8:48 GMT-07:00 Daniel Berlin <span dir="ltr"><<a href="mailto:dberlin@dberlin.org" target="_blank">dberlin@dberlin.org</a>></span>:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span><br>
> Where would license files go on a make install?<br>
<br>
</span>"$CLANG_INSTALL_DIR/share/llvm<wbr>/licenses"? Eventually make the path it an option?<br>
<div class="m_-3476773333820703913gmail-m_5456984594455962221m_-6889126931737582998m_4084837203426538358m_2365711835599172909HOEnZb"><div class="m_-3476773333820703913gmail-m_5456984594455962221m_-6889126931737582998m_4084837203426538358m_2365711835599172909h5"><br></div></div></blockquote><div><br></div></span><div>At least in linux land, most distros have places they expect licenses to go, and it's often part of the packaging format itself.</div><div>For example, debian expects copyright notices to be part of packaging, not installed by the package.<br></div><div>(IE what the patch originally does).</div><div><br></div><div>In particular, it expects it to be a machine parseable format in debian/copyright in the .deb package file.</div><div><br></div><div>This is in turn, parsed and a formatted version put in the right place in the distro.</div><div>They do *not* want packages installing them themselves, AFAIK.</div><div><br></div><div>While i understand why you think this logic should be common, IMHO, it shouldn't be.</div><div><br></div><div>Every single packaging/etc system has a different format, set of rules, etc for what should be happening here.</div><div>There is no real common logic you can extract from this.</div><div><br></div><div>You are going to write logic for rpms, debian, docker, etc anyway right now, to put the bits in the formats and places the distros want them.</div><div><br></div><div>I wish it wasn't the case, of course.</div></div></div></div></blockquote><div><br></div><div><br></div></div></div><div>What I'm saying is there is an apparent need to have in tree:</div><div><br></div><div>1) a way to collect the list of licenses files that needs to be distributed with LLVM.</div><div>2) a way to package them with a LLVM binary distribution.</div><div>3) duplicating this in tree seems bad and not maintainable.</div></div></div></div></blockquote><div><br></div><div><br></div></span><div>I agree, but if every single packaging format wants #1 and #2 in different formats and containing different things, how do you expect to build any common functionality here?</div><span><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><br></div><div>And considering that we haven't even be able to comply with our own distribution (!!) on <a href="http://llvm.org" target="_blank">llvm.org</a>, providing it in the most common unit seems the way to go.</div><div><br></div><div>My assessment right now is that I don't see any drawback to provide this *option* in LLVM and use the CMake option from docker, but on the opposite I see benefits to do it (the LLVM release scripts can be updated to use it right now).</div></div></div></div></blockquote><div><br></div></span><div>Meanwhile, i see no real benefit if every packaging has to turn it off and do something on their own anyway :)</div><div><br></div></div></div></div>
</blockquote></div><br></div></div></div><div class="gmail_extra">I mentioned *two* in-tree packaging that would do the same thing (the LLVM release scripts and the Docker scripts. Two is the right number to factor things isn't it? ;)</div><div class="gmail_extra"><br></div></div></blockquote><div><br></div></div></div>The docker format used here will change shortly (IE in the next few months), and look nothing like something that makes sense for the release scripts.</div></div></div></blockquote><div><br></div><div>Good to hear, but I don't know what you're referring to, was there a discussion on LLVM-dev I missed on this topic?</div><div><br></div><div>I don't have a view of your big plan around this, but maybe you can answer this:</div><div><br></div><div>1) Should the packages on <a href="http://llvm.org">llvm.org</a> include the license?</div><div><br></div><div>2) If the answer is yes, then when the "Docker format" changes to something totally different and this logic to copy the license files dies. We still should address the packages on <a href="http://llvm.org">llvm.org</a> right? In which case refactoring it *now* does not seem to cost much effort but provide the long term benefit that when you stop using it from the Docker scripts it won't be lost and can be used for the LLVM releases packages.</div><div><br></div><div>If you say no to 1), none of my points in this thread make sense and we can move on :) Hope this makes sense?</div><div><br></div><div>-- </div><div>Mehdi</div><div><br></div><div><br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>(It's what i came up with internally).</div><div><br></div><div>In any case, it's clear you think there is some value here.</div><div><br></div><div>I'm just going to say: I did this for many thousands of packages for tens of distros for 10+ years.</div><div>IMHO, there isn't value here until it standardizes more, and that will take many eons.</div></div></div></div></blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><br></div><div>If you want to force someone to do it anyway, okay. I have no desire to die on this hill, i just think it's a waste of time to climb it.</div><div><br></div></div></div></div>
</blockquote></div><br></div></div>