Re: Challenge from Julia's non-standard vendored openblas"64_"
On Mon, Jul 29, 2019 at 9:35 AM Mo Zhou <lumin@debian.org> wrote:
>
> Hi Marco,
>
> After the merger of (64bit-indexing) * (multi-thread flavor)
> feature enhancement, an libopenblas-julia package will
> look abrupt, and break the symmetry of package layout
> (libopenblas-julia doesn't need development files) :
>
> ~/D/o/o/debian ❯❯❯ rg \^Package control
> 19:Package: libopenblas0
> 41:Package: libopenblas0-pthread
> 64:Package: libopenblas0-openmp
> 87:Package: libopenblas0-serial
> 134:Package: libopenblas-dev
> 156:Package: libopenblas-pthread-dev
> 179:Package: libopenblas-openmp-dev
> 202:Package: libopenblas-serial-dev
> 227:Package: libopenblas64-0
> 245:Package: libopenblas64-0-pthread
> 264:Package: libopenblas64-0-openmp
> 283:Package: libopenblas64-0-serial
> 302:Package: libopenblas64-dev
> 321:Package: libopenblas64-pthread-dev
> 341:Package: libopenblas64-openmp-dev
> 361:Package: libopenblas64-serial-dev
>
> Instead, if we embed the openblas source
> to src:julia, no extra binary package is needed.
> So I prefer (3).
>
> It's not the maintenance burden that matters most
> at this point. It's simply that a maintainer doesn't
> want his/her package to look weird.
>
Then we would have two copies of openblas in the archive, which smells
it would look quite weird from FTP Team's perspective.
Regards,
Aron
Reply to: