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

[Mehdi AMINI via llvm-commits]

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? ;)

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/20170928/dd9d11f8/attachment.html>