[PATCH] D38298: A logic to copy LLVM licences into docker images.

[Manuel Klimek via llvm-commits]

On Thu, Sep 28, 2017 at 7:57 PM Mehdi AMINI <joker.eph at gmail.com> wrote:

>
>
> 2017-09-28 10:37 GMT-07:00 Daniel Berlin <dberlin at dberlin.org>:
>
>>
>>
>> On Thu, Sep 28, 2017 at 9:46 AM, Mehdi AMINI <joker.eph at gmail.com> wrote:
>>
>>>
>>>
>>> 2017-09-28 8:48 GMT-07:00 Daniel Berlin <dberlin at dberlin.org>:
>>>
>>>>
>>>>> > Where would license files go on a make install?
>>>>>
>>>>> "$CLANG_INSTALL_DIR/share/llvm/licenses"? Eventually make the path it
>>>>> an option?
>>>>>
>>>>>
>>>> At least in linux land, most distros have places they expect licenses
>>>> to go, and it's often part of the packaging format itself.
>>>> For example, debian expects copyright notices to be part of packaging,
>>>> not installed by the package.
>>>> (IE what the patch originally does).
>>>>
>>>> In particular, it expects it to be a machine parseable format in
>>>> debian/copyright in the .deb package file.
>>>>
>>>> This is in turn, parsed and a formatted version put in the right place
>>>> in the distro.
>>>> They do *not* want packages installing them themselves, AFAIK.
>>>>
>>>> While i understand why you think this logic should be common, IMHO, it
>>>> shouldn't be.
>>>>
>>>> Every single packaging/etc system has a different format, set of rules,
>>>> etc for what should be happening here.
>>>> There is no real common logic you can extract from this.
>>>>
>>>> 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.
>>>>
>>>> I wish it wasn't the case, of course.
>>>>
>>>
>>>
>>> What I'm saying is there is an apparent need to have in tree:
>>>
>>> 1) a way to collect the list of licenses files that needs to be
>>> distributed with LLVM.
>>> 2) a way to package them with a LLVM binary distribution.
>>> 3) duplicating this in tree seems bad and not maintainable.
>>>
>>
>>
>> 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?
>>
>>
>>>
>>> And considering that we haven't even be able to comply with our own
>>> distribution (!!) on llvm.org, providing it in the most common unit
>>> seems the way to go.
>>>
>>> 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).
>>>
>>
>> Meanwhile, i see no real benefit if every packaging has to turn it off
>> and do something on their own anyway :)
>>
>>
> 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? ;)
>

Most people I know would say it's three :)


>
> And I mentioned a CMake option that would be an opt-in, that does not put
> any burden to turn it off for distribution.
>
> --
> Mehdi
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20170929/b6f6b508/attachment.html>