問題タブ [software-packaging]

ソフトウェア tar ボールのユーザーが通常の手順を実行できるように、ソフトウェア パッケージを作成するにはどうすればよいでしょうか。

Debian パッケージ管理ファイル (変更ログ、管理、著作権など) のローカライズ版を提供する方法はありますか?

私はDebhelperを使用してDebianパッケージを作成しています。ファイルとディレクトリをデプロイするには、debian/installとdebian/dirsファイルを使用します。

次に、パッケージでデフォルトのユーザー構成ファイルを$ HOME / .mypackagercにデプロイします（.bashrcやその仲間と同じように）。

Debhelperはこれを行う方法を提供しますか、それとも私は次のことを行う必要がありますか？

• postinstスクリプトで実行します
• または、最初の実行時に、私のプログラムでこれを行うこともできます

私の戦争（Java Webアプリ）とTomcatをexeとしてパッケージ化できる無料のツールはありますか

システム管理者として、RedHat ベースのディストリビューションにインストールする rpm パッケージを提供せず、ソース tarball のみを提供するアプリケーションに遭遇しました。ソース tarball には、rpm パッケージの作成プロセスを簡素化するスペック ファイルが含まれていません。代わりに、ソース tarball は、アプリケーションをシステムにインストールするために root として実行する必要がある bash/ksh/ スクリプトのみを提供します。

基本的にインストール スクリプトを実行してインストール スクリプトを実行する rpm パッケージを作成しようとしました。また、root 以外のユーザーとしてパッケージの rpmbuild を試行し、スクリプトのインストール ディレクトリが rpm 環境/マクロを参照するようにインストール スクリプトをできる限り変更して、正しいことをしようとしました。しかし、数百行の長さの複雑なインストール スクリプトを使用すると、他のスクリプトも呼び出されます...まあ、私はこの努力に失敗する運命にありました。

このような .spec-less ソース tarball をパッケージ化するより良い方法はありますか? より良い解決策は次のとおりです。

1. アプリケーションのインストール前に何らかの方法でシステムのスナップショットを取得する
2. 提供されたインストール スクリプトを使用してソース tarball をインストールします
3. インストール後にシステムのスナップショットを作成し、インストールによって行われた変更/追加を確認します
4. 変更/追加のリストを仕様ファイルに入れて、この方法で rpm パッケージを作成しますか?

この問題に対する有用な/関連性のある/有益な/面白い/深遠な意見やアドバイスをいただければ幸いです。

前もって感謝します

ビルドとメンテナンスを容易にするために、いくつかのコンポーネント (liba、b、c、d) に分割された大規模なプロジェクト (マスター) を手元に持っています。パッケージ全体をビルドする場合、すべてのサブコンポーネントを順番にビルドする必要があり、これらのパッケージの一部は相互に依存しています。

より明確に言えば、liba は b、c、および d の前提条件であり、liba の存在は configure スクリプトによってチェックされます。このチェックは、b ディストリビューションを単独でビルドするときにユーザー フレンドリーなエラー メッセージを表示するために必要です。ただし、マスター パッケージとそのすべてのサブパッケージをビルドする場合、liba はサブターゲットとしてビルドされます。したがって、構成がマスタースイートで実行されると、liba はまだインストールされておらず、b の liba のチェックは失敗します。

--with-liba=internal または同様のフラグを b の構成スクリプトに渡すことで、この問題を修正できます。ただし、このような autoconf のフラグ パッシングに関するドキュメントは見つかりませんでした。当分の間、私は master に非常に長いカスタム Makefile を持っています。これは、サブディレクトリを持つ autoconf/automake とまったく同じことを行いますが、依存関係を少し並べ替えて、代わりに (configure liba) => (configure b) => (build liba) => (ビルド b)、順序は (configure liba) => (build liba) => (install liba) => (configure b) => (build b) です。

標準の autoconf/automake サブディレクトリを使用してこれをリファクタリングする方法はありますか?

私はいくつかのJavaアプリケーションを作成し、無料および商用バージョンで配布することを計画しています.基本的に、私の考えは、企業ユーザーからそれからいくらかのお金を稼ぐことです. 他のユーザーがjarを作成して製品に含めることができる拡張APIを提供したいと思います。

次の質問について教えてください。

1) JAR として配布すると、難読化を行っても、誰でも私のコードを見ることができます。有料の難読化解除ツールがいくつかあると思います..exe または JNI をオプションにしていますが、効果的な解決策ではありません。Microsoft 製品にはこの問題はありません。何かアドバイス？

2)もし私がオープンソースを作ったとしても、ビジネスは通常、IBM websphere や RAD のような巨大な製品でない限りサポートを求めないので、あまり利益を得ることはできません。これを回避するための入力はありますか？

サードパーティが利用できるようにしたいJavaライブラリを完成させています。そのコア機能に加えて、Eclipseプラグインの一部として使用するときにライブラリの使用を容易にするいくつかのクラスを提供しています。次に、ライブラリに特定のOSGi / Eclipseクラス（たとえば、、、、など）への依存関係がorg.osgi.framework.Bundleありますorg.eclipse.core.runtime.FileLocator。org.eclipse.jdt.core.dom.CompilationUnit

だから私の質問は：サードパーティの使用のためにこのライブラリをパッケージ化するための正しい/便利な方法は何ですか？必要な依存関係を含むすべてのEclipsejarを含める必要がありますか？直感的には、ユーザーが私が持っているものとは明らかに異なるEclipseバージョンを持っている可能性があり、これがクラスの読み込みの競合につながる可能性があることを考えると、これは良い解決策ではないと思います。Eclipse jarを提供せず、ユーザーに好きなものを見つけるように依頼するという解決策も、私を納得させるものではありません。

私はMavenの経験があまりありませんが、私が理解している限り、ユーザーがプロジェクトの最後のバージョンとその依存関係をダウンロードするために使用できるPOMファイルを作成できます。しかし、繰り返しになりますが、その場合は、上記の理由を考慮して、ダウンロードにEclipsejarを含めるかどうかも決定する必要があります。

この点に関してあなたの経験を共有してくれてありがとう。

私たちの店はPythonショップです。社内で開発されたさまざまなPythonパッケージがあり、お客様の環境（マシン）にデプロイされます。

これが私たちの開発とリリースサイクルがどのように行われるかです。

開発者がパッケージの「テスト」を完了すると、パッケージの配布（eggファイル）が準備され、中央のアーカイブ場所にプッシュされます。お客様にソフトウェアを展開する場合、同じディストリビューション（eggファイル）がダウンロードされ、お客様の環境にインストールされます。

「テスト」が複数のオペレーティングシステムで行われると仮定すると（プラットフォーム間のAPIの互換性を確認するため）、ディストリビューションを準備して中央のアーカイブ場所にプッシュするためのベストプラクティスは何ですか。

アーカイブサーバーにオペレーティングシステム固有の卵を置くのが最善ですか（たとえば、samplepkg-1.0.0.win32.eggやsamplepkg-1.0.0.linux.egg？setuptoolsを使用してこの方法で卵を準備する方法がわかりません）。または、APIはプラットフォーム間で同じままなので、単一の卵を持っていますか？コミュニティが従う他の慣行はありますか？

スタンドアロン Java SE (コマンド ライン ベース) アプリケーションの標準的なプロジェクト ディレクトリ構造は何ですか?

srcフォルダーには.java、適切に編成されたパッケージにすべてのファイルが含まれます。それ以外にbin、ファイルを含むフォルダーがあり.classます。

プロジェクトにプロパティ ファイルと XML 構成ファイルがあります。どのディレクトリに配置すればよいですか? という名前のパッケージを作成し、その中にcom.myproject.configすべての構成.xmlファイルを配置する必要がありますか?

依存する jar を最終パッケージと一緒にパッケージ化したいと考えています。libこれらすべての.jarファイルを保持するフォルダーを作成する必要がありますか?