Re: Challenge from Julia's non-standard vendored openblas"64_"
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.
On 2019-07-29 00:12, Marco d'Itri wrote:
> On Jul 28, Mo Zhou <lumin@debian.org> wrote:
>
>> 2. Specifically compile a libopenblas64_.so
>> from src:openblas for julia's use.
>> This looks very bad for src:openblas's
>> package layout.
> Why would this look bad? We have plenty of source packages which
> generate multiple variations of binary packages.
> udebs, for a start. Many libraries which generate both a static and
> dynamic package. The older inn2 releases if you want to see something
> really ugly.
> While this solution may require some packaging work it is obviously both
> the technically correct one and the one which will not harm users.
Reply to: