Update netcdf from 4.3.3.1 to 4.6.1

[thomas]

This accompanies #901.

[donald]

/usr/bin/gdl seems to be using libnetcdf.so.7 which would be removed by this update.

[donald]

Ah, you already had it in #901. Are you going to push the updates of the dependent packages on this PR?

[thomas]

Right now there is a new PR for GDAL in preparation.
I can't tell whats really better, one request for everything, but where to stop in the dependency chain?
So I prefer a common issue that mentions all the separate targets (since they also light up so neatly in the issue)

[pmenzel]

On 09/05/18 16:57, Thomas Kreitler wrote: I can't tell whats really better, one request for everything, but where to stop in the dependency chain?

A merge/pull request should contain all changes, so that after the merge and package changes, the system is in a working state and all dependencies are installed.

So I prefer a common issue that mentions all the separate targets (since they also light up so neatly in the issue)

An issue is good too, and it of course depends on the issue. There can be an issue to clean up all bee files, and there can be several merge/pull requests for that issue, but each merge/pull request keeps the installation in a working state.

[donald]

Yes, make it one pull request, please.

[thomas]

"A merge/pull request should contain all changes, so that after the merge and package changes, the system is in a working state and all dependencies are installed."

Das beantwortet nur nicht die frage, wie man eine abhaengigkeits kette (die sehr lang werden kann) in einem pull request behandeln soll, was ist mit kreuz abhaengigkeiten (brauche neues A um B bauen zu koennen, A benoetigt aber B). Und wie gut das mit dem 'alles in einem PR' funktioniert sieht man ja in #805. Hinzu kommt, dass das notwendige update von gnudatalanguage-gdl in #805 einfach versackt ist.

Ansonsten ist obiger beitrag ja wohl nur 'mimimi' auf sechstklaessler niveau. Kleiner tipp am rande: das laufende system ist bereits 'brocken', da etliche programme wg. fehlender libraries nicht laufen.

Aber da jetzt ja lieber um etwas 'gebeten' wird, anstelle das problem einvernehmlich zu loesen ist mir die sache ehrlich gesagt latte.

[donald]

Das beantwortet nur nicht die frage, wie man eine abhaengigkeits kette (die sehr lang werden kann) in einem pull request behandeln soll, was ist mit kreuz abhaengigkeiten (brauche neues A um B bauen zu koennen, A benoetigt aber B).

Doch, tut es: Alles in einen PR, was nur zusammen en-block installiert werden kann. In obigem Beispiel A und B in einen pull-request.

Und wie gut das mit dem 'alles in einem PR' funktioniert sieht man ja in #805.

Was ist das Problem mit #805 (abgesehen davon, dass er natürlich auch mit einem pull request angefangen hat, bei dem die shared libraries nicht überprüft wurden) ? David hat netterweise die abhängige Software auch mit reingenommen. Alles schick.

Hinzu kommt, dass das notwendige update von gnudatalanguage-gdl in #805 einfach versackt ist.

Ja, das ist doof. Noch blöder, dass er vermutlich okay war, aber hinterher (#879 "Update imagemagick from 6.9.4 4 to 6.9.10") gemerged wurde und ebenfalls nicht geprüft wurde, ob der eine benötigte shared library weghaut.

Ansonsten ist obiger beitrag ja wohl nur 'mimimi' auf sechstklaessler niveau.

wtf? Du hast gefragt, welche Variante besser ist und Paul und ich haben auf die Frage geantwortet.

Kleiner tipp am rande: das laufende system ist bereits 'brocken', da etliche programme wg. fehlender libraries nicht laufen.

Dass /usr/bin/gdl noch aus anderen Gründen nicht geht, war mir nicht bewusst, was aber, wie gesagt, an (#879 "Update imagemagick from 6.9.4 4 to 6.9.10") liegt. . Und es war ja auch nur ein Beispiel, mysql-workbench ist ja genauso und die geht zur Zeit wohl noch.

Aber da jetzt ja lieber um etwas 'gebeten' wird, anstelle das problem einvernehmlich zu loesen ist mir die sache ehrlich gesagt latte.

Ja, schon gut, ich übernehme das.