タグ付けされた質問 「package-managers」

9
ライブラリフォルダーよりもパッケージマネージャーを好むのはなぜですか?
静的ライブラリフォルダーとパッケージマネージャーの長所と短所を考えると、ライブラリフォルダーの方が良いアプローチだと思います。 ライブラリフォルダーで表示される長所: パッケージを管理するための外部ツールは必要ありません。 構築にインターネット接続は必要ありません。 ビルドの高速化(パッケージチェックなし)。 よりシンプルな環境(必要な知識が少ない)。 パッケージマネージャーで見られる長所: 複雑な依存関係ツリーを支援します(依存関係とそのすべての依存関係をダウンロードして管理できます)。 利用可能な新しいバージョンがあるかどうかを確認するのに役立ちます。 業界は、今日構築されているほぼすべてについて、パッケージマネージャーパスに従うことを決定したようです。だから、私は何が欠けていますか?

8
開発者がLinuxでインストールウィザードを作成しないのはなぜですか?[閉まっている]
怠lazなどの問題ではないと確信していますが、主に消費者向けアプリの開発者でも、次から次へと進むインストールウィザードを作成しない理由を理解できません。通常、同じアプリにはWindowsとMac OSのインストーラーがあります。Linuxではどうですか? この傾向には技術的な理由がありますか、それとも単なる慣習ですか? 編集(2014年9月9日):この質問は、Windows対Linuxのフレーム戦争を開始するように依頼されていません。私は3つの主要なオペレーティングシステムすべてを使用しましたが、Linuxを除き、他の2つ(WindowsとMac OS)には両方ともインストーラーがあります。Oracleはまだインストールしていませんが、インストールに必要なものは何でも、Linux用のGUIインストーラーを見たことはありません。 はい、Linuxにはパッケージマネージャーがあるため、開発者がインストーラーを作成する必要はありません。しかし、デフォルトのパッケージマネージャーでは時代遅れであるか、単に利用できないという膨大な量のソフトウェアがまだあります。さらに、Linuxはカジュアルユーザー向けのWindowsの代替として販売されているため(Ubuntuはこのドメインで一生懸命努力しています)、ユーザーになじみのある情報を提供する方がはるかに理にかなっています。 たとえば、LAMPスタックをセットアップします。これらはすべてデフォルトリポジトリのオープンソースソフトウェアですが、スクリプトなしですべてを一度に設定できますか?次に、WindowsのWAMPサーバーを見てください。インストーラーを実行するだけで、複数のソフトウェアが相互に機能するようにインストールされます。次に、適切なデフォルトなどを設定します。インストーラーはそれを行うことができますが、パッケージマネージャーはできません。はい、そのオンライン用のスクリプトを見つけることができますが、どこですか?そしてどれ? インストーラーは、過去の時代遅れのテクノロジーではありません。それらはまだ有用であり、95%のユーザーは既にそれらに満足しています。

3
使用されているすべてのNuGetパッケージのライセンス情報を取得する
家を整理するために、マニュアルでプロジェクトの依存関係のライセンスを手動で追加するのではなく、自動的にアセンブルします。 CSPROJファイルのセットをプログラムで走査し、参照されたパッケージのライセンス情報をリンクまたは文字列として抽出する簡単な方法を知っている人はいますか?

6
パッケージマネージャーは.bashrcファイルを変更する必要がありますか?
適切に実行するために環境変数を設定する必要がある何かのためのパッケージを書いています。パッケージマネージャーのインストール手順でユーザーの環境を変更する必要がありますか、それともユーザーに自分で変更するように促すだけですか?私の直感は後者ですが、私は前者の議論を見ることができます。

7
有料ソフトウェア更新のためのAptリポジトリの使用
毎週または毎月更新される可能性がある、ホストされた/オンサイトのWebアプリケーションのソフトウェア更新を配布する方法を決定しようとしています。オンサイト製品を使用しているお客様に手動での更新について心配する必要はありません。GoogleChromeから自動的にダウンロードしてインストールするだけです。Ubuntuとインストールおよび構成されたソフトウェアを含むOVFファイルを提供することを計画しています。 ソフトウェアの分散方法について最初に考えたのは、鍵を使用してSSH経由でアクセスされる6つのAptリポジトリ/チャネル(現時点ではどちらが良いかわからない)を作成することです。そのため、顧客がサブスクリプションを更新しない場合は、アカウントを無効にできます。 : ベータ-パッケージに重大な欠陥がないかどうかを確認するためにテストデータで内部的に使用されます。 内部-パッケージの欠陥をチェックするためにライブデータで内部的に使用されます(ドッグフード段階)。 外部1-ユーザーベースの1%に展開(ランダムに選択)して欠陥をチェックします。 外部9-ユーザーベースの9%(ランダムに選択)に展開され、欠陥をチェックします。 外部90-残りの90%のユーザーに展開されます。 ホスト-ホストされた環境にデプロイされます。 問題が報告された場合、次のリポジトリに移動するために、各段階でサインオフします。 コミュニティへの私の質問は次のとおりです。 誰かが以前にこのようなことを試しましたか? 誰もがこのタイプの手順のマイナス面を見ることができますか? もっと良い方法はありますか?
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.