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 <lu...@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.
