On Tue, May 12, 2020 at 12:08 PM Lausen, Leonard <lau...@amazon.com.invalid>
wrote:

> On Mon, 2020-05-11 at 13:56 -0400, Carin Meier wrote:
> > Does removing the jars from both of these solutions also remove them from
> > maven central?
>
> Does Maven Central automatically mirror jars from repository.apache.org?
> Or were
> these jars uploaded there manually?
>

The jars are automatically mirrored. This implies that we remove them from
Maven Central as well.

> > 1) Ask the Infra team to delete all MXNet releases on
> > > repository.apache.org
> > > 2) Ask the Infra team to delete all MXNet GPU releases on
> > > repository.apache.org
> > > and provide replacement releases without libgfortran.so and other
> > > potentially
> > > Category-X files (I found libmkl_ml.so in one of the JARs..)
> >
> > If so, either of these options has potential to cause major disruption
> for
> > users that depend on using them in production. If either of these actions
> > are deemed necessary, we should strive to provide communication to end
> > users and a solution for a process of how to replace them.
>
> Do you have any recommendation for the replacement plan? Would users be
> fine
> with releases not including libgfortran.so? Thus the releases will only
> work on
> machines that come with libgfortran.so preinstalled. Or can we just ask
> them to
> build from source? I don't think anyone has volunteered yet to handle
> fixing the
> old JVM releases, so the current requirement may be to ask JVM users to
> build
> from source.
>
>
I would also like to ask how we use libgfortran? Since it is category X, we
should not be depending on it for any of the core functionality in MXNet.
It can only have an "optional feature" (
https://www.apache.org/legal/resolved.html#optional) at most. Furthermore,
libgfortran seems to be under the full GPL (
https://github.com/gcc-mirror/gcc/blob/master/libgfortran/libgfortran.h)
instead of the LGPL, so I don't know if we are even allowed to even have it
as an optional dependency.

Reply via email to