OpenBLAS binary packages

[Artur Szostak]

I get and understand your concerns. Consider my comment as giving a data point from real world use in the wild. You already seem to be aware of the trade offs and consequences of technology choice and policy decisions related to package managers and how they are used.

As for bug reports: We have made these as and where necessary. However, if you want earlier and better feedback, I can only suggest to make this process trivial for the end users, i.e. the goal would be the equivalent of one click reporting. This is hard to implement properly though, without exposing the project to abuse (e.g. spam etc.) and keeping end user security in mind. If done right however,  I think this could be a significant improvement to the project overall.

________________________________________
From: Mojca Miklavec <mojca at macports.org>
Sent: 15 May 2019 22:44:29
To: Artur Szostak
Cc: macports-users at lists.macports.org
Subject: Re: OpenBLAS binary packages

On Wed, 15 May 2019 at 12:23, Artur Szostak <aszostak at partner.eso.org> wrote:
>
> After our 4 years of experience preparing RPM and MacPorts package repositories of our software we have seen that MacPorts packages take an order of magnitude more time to build and cause significantly more problems than RPMs. Mainly because there is a non-trivial probability that some port in the dependency tree will start breaking, and there is no way to pin or encode version ranges for the Portfile dependencies to prevent this.

On top of what Ryan replied ...

1.) Most linux distributions simply freeze all the software. If you
want something newer, you need a newer distribution. That's a lot
easier to test.

>From what I remember CentOS 6(?) doesn't even have proper support for
C++11 out of the box.

If you take a rolling release like Arch linux or Debian experimental
you are also highly likely to run into various issues; you would
usually run at least Debian testing or even stable, and simply live
with ancient software that never gets updated except for security
patches. If you freeze the software, you can do a lot more testing. We
could also freeze all software with every major OS release, but that
would make the distribution much less attractive (not to say mostly
useless). While it would be useful to have a model similar to Debian
with some experimental and stable branches of MacPorts, we simply
don't have sufficient workforce to do that.

If we now update libpng, we should theoretically test (build from
source and run the test suite) every single package that depends on
libpng, and we don't even have CPU capacities to do such kind of
testing.

2.) We have too many abandoned packages and lots of broken software,
so it's nearly impossible to differentiate between something that's
not used by anyone and should have been axed years ago, and software
that's used by many and has only recently been broken. Part of this
will hopefully be easier to monitor after this summer with one of the
GSOC projects.

Mojca