On Mon, Feb 27 2017, Ricardo Wurmus wrote
> Carlo Zancanaro <carlo@zancanaro.id.au> writes:
>> But then I wondered, could we just change the generate-keystore phase of
>> the icedtea-6 package to log a failed certificate import without failing
>> the build? Then we could move the permissions change there, too, which
>> would give us a smaller patch that should accomplish a similar result
>> (attached).
>
> Hmm, I have a slight preference to have the build fail in those cases,
> because that prompts us to fix the underlying problem.  Roel’s fix seems
> more direct, even though it results in more lines of code.

Sure, but then we get a situation like we currently have: the build
fails, so the keystore generation is disabled (rather than fixed) and we
have a Java package that is heavily crippled (especially for development
purposes).

If it failing actually lead to people fixing the issue then I would be
fine with that, but the issue I have is that it doesn't get fixed, it
gets disabled. I'd much rather have it work for most use cases, rather
than failing on the slightest hiccup.

My issue isn't that Roel's fix is more lines of code, it's that it is
more brittle, it hard codes package information, and it results in
unnecessary duplication of code.

>> @@ -719,6 +719,15 @@ build process and its dependencies, whereas Make uses Makefile format.")
>>                                         "/lib/security"))
>>                 (mkdir-p (string-append (assoc-ref outputs "jdk")
>>                                         "/jre/lib/security"))
>> +
>> +               ;; The cacerts files we are going to overwrite are chmod'ed as
>> +               ;; read-only (444) in icedtea-8 (which derives from this
>> +               ;; package).  We have to change this so we can overwrite them.
>> +               (chmod (string-append (assoc-ref outputs "out")
>> +                                     "/lib/security/" keystore) #o644)
>> +               (chmod (string-append (assoc-ref outputs "jdk")
>> +                                     "/jre/lib/security/" keystore) #o644)
>> +
>
> I don’t understand this.

What don't you understand about it? If the comment is unclear then I am
happy to clarify it further.

> It also seems inelegant to make a change in “icedtea-6” for the sake
> of “icedtea-8”. Could this be done in “icedtea-8” instead?

I agree that it's inelegant, but the alternative is to duplicate the
entire phase and make the changes in icedtea-8. Given we are using
inheritance for code re-use here, I don't think it's too bad to do
something that's always valid to fix a problem in a specific case.

> Also note that icedtea-6 will eventually be removed (as it will no
> longer receive upstream updates) and the other icedtea* packages should
> no longer use inheritance to make that possible.

The 'install-keystore phase will have to be moved to icedtea-7, then,
where the same code will be required. The phase will have to move at
some point anyway, so I don't think this is particularly significant
that it's currently in icedtea-6.

Carlo