On Wed, 15 May 2019 at 12:23, Artur Szostak <aszos...@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