タグ付けされた質問 「repository」

公式リポジトリなしでローカルリポジトリのみでQGISをセットアップするベストプラクティスはありますか？ この背後にある考え方は、ローカルGIS管理者がプラグインをローカルリポジトリに追加する前にチェックする安定した環境をセットアップすることです。 プラグインに問題があり、QGISインストールが不安定になりました（例：https://github.com/vinayan/RectOvalDigitPlugin/issues/6）。800人のプラグインを自由に選択するよりも、ソフトウェアの信頼性が同僚にとって重要であるため、利用可能なプラグインを事前に選択します。 結局のところ、ユーザーがプラグインディレクトリとして不要な/不安定なプラグインをインストールすることを防ぐためにQGISインストールをセットアップする必要がある人はおそらく不可能であり、QGIS2.iniはユーザーによって書き込み可能でなければなりませんが、 QGIS作業環境をもう少し安定させるために。 私のアイデアは次のとおりです。 ローカルリポジトリを削除し、「追加」ボタンを非表示にしますか？ プロキシを介して公式リポジトリをブロックしていますか？ 許可されたプラグインにホワイトリストを使用し、QGISプログラムフォルダーにインストールされたプラグインを使用して、ホワイトリストに対してインストールされたプラグインをチェックしますか？ ビジネスITインフラストラクチャでQGISをセットアップした経験のある人はいますか？

16 qgis  qgis-plugins  repository 

ソースからビルドせずにCentOS7にGDAL 2.Xをインストールしようとしています。別のサーバーでGDAL 2.Xを構成する必要があり、ソースコードによるインストールは非常に時間と手間がかかる作業です。 opengeoやELGISなどのリポジトリをいくつか見つけましたが、CentOS7用です。EPELリポジトリでは、GDAL 2.xが利用できません。 [root@localhost ~]# yum repo-pkgs epel list gdal* (...) Available Packages gdal.x86_64 1.11.4-1.el7 @epel gdal-libs.x86_64 1.11.4-1.el7 @epel gdal-python.x86_64 1.11.4-1.el7 @epel gdal-devel.x86_64 1.11.4-1.el7 @epel gdal-doc.noarch 1.11.4-1.el7 @epel gdal-java.x86_64 1.11.4-1.el7 @epel gdal-javadoc.noarch 1.11.4-1.el7 @epel gdal-perl.x86_64 1.11.4-1.el7 @epel バージョン1.11は、1.xメジャーバージョンの最新版ではありません。 任意のリポジトリからインストールすることはできますか、それともソースからのみインストールできますか？そうでない場合、RPMとしてビルドして複数のサーバーに簡単にインストールできますか？

15 gdal  centos  repository