web-dev-qa-db-ja.com

実行可能ファイルをインストールする方法

.debまたは.rpmでは提供されないが実行可能ファイルとしてのみ提供されるソフトウェアに遭遇することがあります。
例 Visual Studio Code 、 WebStorm または Kerbal Space Programm 。

この質問では、Visual Studioコードを参照ポイントとして使用します。

ソフトウェアは、圧縮パッケージとして提供されます。
解凍すると、Codeという名前の実行可能ファイルを含むVSCode-linux-x64というフォルダーが残ります。
Codeをダブルクリックするか、/home/user/Downloads/VSCode-linux-x64/Codeなどのターミナルでポイントして実行できます。
しかし、このアプリケーションをインストールする適切な方法があるかどうか知りたいのですが。

私が達成したいのは：

  • この方法で提供されるすべてのアプリケーション/ソフトウェア（実行可能ファイル）を配置できる1つの場所
  • ターミナルサポート（つまり、ターミナル内の任意のフォルダーからvscodeを書き込むことができ、Visual Studioコードが自動的に実行されます。

追加情報：

  • デスクトップ環境：Gnome3
  • OS：Debian

編集：
彼のアプローチが私のバックアップソリューションでうまく機能するため、@ kbaに答えを出すことにしました。スクリプトでバイナリを実行すると、引数を追加することができます。
しかし、公平に言うと、@ John WH Smithのアプローチは、@ kbaのアプローチと同じくらい優れています。

software-installationgnome3executable
13
Harrys Kavan

名前でプログラムを呼び出すために、シェルは$PATH環境変数のディレクトリを検索します。 Debianでは、ユーザーのデフォルトの$PATHに/home/YOUR-USER-NAME/binを含める必要があります（つまり、~/bin）。

最初に、ディレクトリ~/binが存在することを確認するか、存在しない場合は作成します。

mkdir -p ~/bin

バイナリをそのディレクトリにシンボリックリンクして、シェルで使用できるようにすることができます。

mkdir -p ~/bin
ln -s /home/user/Downloads/VSCode-linux-x64/Code ~/bin/vscode

これにより、コマンドラインまたはコマンドランチャーからvscodeを実行できます。

注：バイナリを$PATHディレクトリにコピーすることもできますが、相対パスに依存していると問題が発生する可能性があります。

ただし、一般的には、OSが提供する手段（apt-get、debパッケージ）またはソフトウェアプロジェクトのビルドツールを使用してソフトウェアを適切にインストールすることが常に望ましいです。これにより、依存するパス（起動スクリプト、マニュアルページ、構成など）が正しく設定されます。

更新：Thomas Dickeyのコメント と Faheem Mithaの回答 も反映しています。トップレベルのバイナリを含むtarballとして提供され、そこから実行されることを想定しています。

それを正しい場所に置きます（標準に準拠した順 /opt 、 /usr/local またはホームディレクトリ内のフォルダー、たとえば~/build）、$PATHに実行可能なスクリプトラッパーを作成しますその場所に変更してバイナリを実行する場所（例：/usr/local/binまたは~/bin）：

#/bin/sh
cd "$HOME/build/directory"
exec ./top-level-binary "$@"

これにより、そのディレクトリへの変更とバイナリの手動実行がエミュレートされるため、存在しない相対パスなどの問題のデバッグが容易になります。

12
kba stands with Monica

[〜＃〜] tldp [〜＃〜] によると、/optはこの種のソフトウェアに適した場所かもしれません。私は自分でいくつかのプリンター関連ツールと「動的」バージョンのSkypeを格納するために使用しました（kbaが言ったように、「PATH変数を適宜設定することで「端末サポート」を実現できます）。

より一般的には、/optを使用して、実行可能ファイルとしてパッケージ化された専用ソフトウェアを「インストール」する傾向がありますが、それはおそらく私だけです。その上、私はこの種のソフトウェアを単に回避する傾向があります。なぜなら、私がそれを実行した後、それが何をするかについては通常確信がないからです。

/optを選択したもう1つの理由は、/opt/'package'ディレクトリ（およびその他のoptディレクトリ以外のファイルに依存しない、サードパーティの独立したコードを対象とするためです。 /etc/optなど）。

正常に機能するためにファイルシステムツリー内の特定の場所に存在する必要があるパッケージファイルを除いて、/ opt、/ var/opt、/ etc/opt階層の外に他のパッケージファイルが存在することは決してありません。 [...]通常、システム上のパッケージをサポートするために必要なすべてのデータは、/ etc/opt/'package'および/ var/opt/'にコピーされるファイルを含め、/ opt /' package '内に存在する必要がありますパッケージ」および/ opt内の予約済みディレクトリ。

ソースコードをリリースする利点の1つは、コンパイルプロセスを構成し、システムの詳細に基づいてカスタムライブラリ/ヘッダーパスを提供できることです。開発者がコードを実行可能ファイルとしてリリースすることを決定すると、その利点は失われます。私見では、この時点で、開発者は自分のプログラムの依存関係が利用可能であると想定することはできません（そのため、実行可能ファイルと一緒にすべてをパッケージ化する必要があります）。

ここにインストールするパッケージは、静的ファイル（つまり、追加のフォント、クリップアート、データベースファイル）を別の/ opt/'package'または/ opt/'provider'ディレクトリツリーに配置する必要があります（Windowsのインストール方法と同様です）独自のディレクトリツリーへの新しいソフトウェアC：\ Windows\Progam Files\"Program Name"）。ここで、「package」はソフトウェアパッケージを説明する名前で、「provider」はプロバイダーのLANANA登録名です。

詳細については、/optと/usr/localの違いを扱う このU＆Lに関するその他の質問 もお勧めします。この場合、個人的には/usr/localを避けます。特に、私が built プログラムを実行する人でない場合は、インストールしています。

8
John WH Smith

Visual Studio Codeの例のように、バイナリZipアーカイブまたはtarballから配布バイナリパッケージを作成することは完全に可能であり、実際には非常に簡単です。

はい、debsやrpmsなどのLinuxディストリビューションバイナリパッケージは、通常、ソースから生成されますが、そうである必要はありません。また、結果として得られるディストリビューションバイナリパッケージが、ディストリビューションポリシーに準拠するために「適切な」場所にインストールするように、多くの場合（常にではありません）を調整できます。

ランダムな独自のtarballの場合、ソフトウェアを適切にインストールする方法があった場合。 makefileのインストールターゲット。配布パッケージングマシンで使用できます。そうでない場合、これには「手動」でファイルを「正しい」場所にマッピングすることが含まれる可能性があり、多くの作業になる可能性があります。このようなパッケージを作成するのは奇妙に思えるかもしれませんが、パッケージ管理の主な利点の1つであるクリーンインストールとアンインストールは依然として存在します。そしてもちろん、そのようなパッケージはその名前に値するどのLinuxディストリビューションにも受け入れられませんが、それはあなたの質問ではありません。

6
Faheem Mitha