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 <[email protected]> Sent: 15 May 2019 22:44:29 To: Artur Szostak Cc: [email protected] Subject: Re: OpenBLAS binary packages On Wed, 15 May 2019 at 12:23, Artur Szostak <[email protected]> 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
