Update README.md to mention Debian presence

[fgvanzee]

Update the External Linux packages section of the README.md file to properly credit/acknowledge our sponsor within the Debian universe, as well as mention any information that Debian users may find useful or helpful in learning about how to use BLIS "natively" within the Debian distribution.

@cdluminate I invite you to suggest some language, bullet points, or other content that you think would be appropriate. I'm not very familiar with Debian/Ubuntu or its packaging terminology, and still have many questions, but none of them need to be answered immediately. :)

I envision replacing the current External Linux packages section with something along the lines of:

(Suggested additions/changes are welcome. Thanks.)

External Linux packages

Generally speaking, we highly recommend building from source whenever possible using the latest git clone. (Tarballs of each tagged release are also available, but we consider them to be less ideal since they are not as easy to upgrade.)

That said, some users may prefer binary and/or source packages through their Linux distribution. Thanks to generous involvement/contributions from our community members, the following BLIS packages are now available:

• Debian. M. Zhou has volunteered to sponsor and maintain BLIS packages within the Debian Linux distribution. The downstream Debian repository for BLIS can be found here. (Also, thanks to Nico Schlömer for previously volunteering his time to set up a standalone PPA.)
• Red Hat/Fedora. Dave Love provides rpm packages for x86_64, which he maintains at Fedora Copr.

[cdluminate]

Official debian binary package is still not available though.

IHMO there is no need to point out the packaging repo URL to users, because most of them don't even know how to create .deb packages from such repo. Instead of the packaging repo URL, the tracker page, e.g. [1], should be the most useful link to both upstream and users to track official debian package status. And the link pointing to git repo is already provided by the tracker page.

So I suggest the following change:

-The downstream Debian repository for BLIS can be found here. 
+The downstream Debian package status for BLIS can be found here. 

However the BLIS package has not been uploaded to the Debian archive, so there is not such tracker page for blis yet.

Apart from that, a brief hint about how to install the binary package with APT would be useful, since the resulting binary package won't be named as blis. BLIS will be split into libblis-dev (headers) and libblis1 (shared object). For development purpose the user should install libblis-dev.

[1] https://tracker.debian.org/pkg/intel-mkl
https://tracker.debian.org/pkg/openblas

[fgvanzee]

Official debian binary package is still not available though.

Sorry for the misunderstanding. I'll leave this issue open as a reminder to update the README.md once BLIS has been uploaded to the Debian archive.

Apart from that, a brief hint about how to install the binary package with APT would be useful, since the resulting binary package won't be named as blis. BLIS will be split into libblis-dev (headers) and libblis1 (shared object). For development purpose the user should install libblis-dev.

Thanks for this suggestion. Just out of curiosity, what is the significance of the "1" in the libblis1 package name?

[cdluminate]

Appending SOVERSION such as 1 to library package names helps keep upgrading safty in terms of API/ABI change. For example:

No SOVERSION, Before Upgrade and After Partial upgrade:
appA (depends on: libfoobar, libfoobar.so.1)  => appA (depends on: libfoobar, libfoobar.so.2)
appB (depends on: libfoobar, libfoobar.so.1) => appB (depends on: libfoobar, libfoobar.so.1)
 -> appB breaks because libfoobar no longer provide libfoobar.so.1

SOVERSION, Before and After Partial upgrade:
appA (libfoobar1, libfoobar.so.1) => appA (libfoobar2, libfoobar.so.2)
appB (libfoobar1, libfoobar.so.1) => appB (libfoobar1, libfoobar.so.1)
 -> appB is still healthy because libfoobar1 and libfoobar2 co-exist on the system.
 ->  libfoobar1 can be removed when there is no any package depending on it

Careless partial upgrade on some linux distributions (a.g. Archlinux) might result in a disaster. However Debian is relatively safer in such case.

[fgvanzee]

@cdluminate Thanks for that detailed example. Makes perfect sense. (I suspected the "1" was the shared object version, but wasn't 100% sure and didn't yet appreciate the reason behind including it.)

[cdluminate]

Citing Debian Policy In case anyone is interested in the detail: https://www.debian.org/doc/debian-policy/ch-sharedlibs.html

[cdluminate]

Preliminary Debian package (targeted at Debian unstable) is available here: http://debomatic-amd64.debian.net/distribution#unstable/blis/0.4.1-1/buildlog

There is still one thing to be done before uploading to the official archive: check every file for copyright. This may take a long time.

[fgvanzee]

@cdluminate Thanks for the update. Can you explain the purpose of this copyright review you need to perform? What are you looking for? Or what condition are you trying to ensure?

[cdluminate]

@fgvanzee Copyright checj is simply required by Debian. FTP master will definitely reject the package if the copyright info is not complete. Nothing for upstream to do

[fgvanzee]

Understood. Virtually all of the source code and header files should have copyright comment blocks. Some build system files and documentation files do not contain them, however.

[cdluminate]

This issue can be marked as pending. #254 (comment)

[fgvanzee]

@cdluminate Thanks. I will update the README.md file according to the changes suggested previously by you and I. This new README.md will be included in 0.5.1.

[fgvanzee]

Instead of the packaging repo URL, the tracker page, e.g. [1], should be the most useful link to both upstream and users to track official debian package status. And the link pointing to git repo is already provided by the tracker page.

@cdluminate I'm preparing the revision to the README.md discussed earlier in this issue. What will the tracker URL be for BLIS? Will it be https://tracker.debian.org/pkg/blis ?

[cdluminate]

Instead of the packaging repo URL, the tracker page, e.g. [1], should be the most useful link to both upstream and users to track official debian package status. And the link pointing to git repo is already provided by the tracker page.

@cdluminate I'm preparing the revision to the README.md discussed earlier in this issue. What will the tracker URL be for BLIS? Will it be https://tracker.debian.org/pkg/blis ?

Yes, that's the link, altough the page still missing currently. Note that the time required for ftp team to review is unsure... it may take several days to weeks... but I think it's fine to document this in advance.

[fgvanzee]

Yes, that's the link, altough the page still missing currently. Note that the time required for ftp team to review is unsure... it may take several days to weeks... but I think it's fine to document this in advance.

Agreed. (And several days to weeks is fine with us.) If anyone reports the broken link (a) this will mean people are paying attention and interested in Debian packaging! and (b) we can simply assure them that the link will be active soon.

Thanks again!

[cdluminate]

This issue can be closed now.

[fgvanzee]

Thanks, @cdluminate!