多くの人が、Mandrivaの古いアセンブリツールを使用して変更を加える方法に関心を示しています。 実際、NPPの第1ステージでのペンギンの勝利と、その結果、R＆D ROSDにアセンブリシステムを提供するというタスクにより、私たちの控えめなチームは、ROS / Mandrivaで開発されているユニバーサルビルドサーバーABFの内部プロジェクトを公開する機会を得ることができます。
私たちはロシアでこのプロジェクトを開始し、パッケージの再組み立て中に自動化された依存関係マッチングの長年のアイデアを実装しました。 つまり、ABFは、すべての依存関係の再アセンブリに到達するまで、新しいパッケージが失敗しないように（およびリポジトリで終了しないように）機能します。 合意された再構築手順により、 リングの依存関係を処理します。 その結果、一連のパッケージ（およびそのための配布とプログラム）のアセンブリの正確性と再現性が達成されると、メンテナーの不注意な行動（ABFイデオロギー学者はFedoraの派生物を構築する前の人生で対処しなければならなかった）によってさらに侵害されませんマンドリバ）。 メンテナーが低品質のパッケージを提供する場合、彼はそれをすぐに自動的に受け取り、それをやり直す指示を受け取ります。
ROSA / Mandrivaのシステムアーキテクトによると、ディストリビューションを構築する際の継続的な統合は、多くの場合、さまざまな程度の新鮮さのパッケージからの毎日のアセンブリの事実ではなく、はるかに大きい-イメージ内のすべてのパッケージが組み立てられるというビルドマネージャーの信頼互いに競合することなく、ローカルに適用された一連のテストだけでなく、全体としてこれを確認する必要があります。 他のパッケージのアセンブリパッケージによる違反が偶然に手動で検出され、リビルドの要求が反応を保証することなくメーリングリストに手動で配置されることは、奇妙に思えます。 これは最後の世紀です。
構造的には、ABFは単一のコードリポジトリで動作し、単一のディスパッチャーバランサーから管理される、ビルドクライアント（さまざまなプラットフォームとアーキテクチャ用）の拡張可能な分散セットです。 Mandrivaおよび多くのRHデリバティブのビルドクライアントはすでに存在します。つまり、異なるディストリビューションが統一された方法で組み立てられています。 このインフラストラクチャにアクセスするプラットフォーム/ディストリビューションの開発者は、テンプレートに基づいて独自のアセンブリバックエンドを作成し（元のアセンブリ手順のスクリプトフラグメントを使用）、ソースコードをリポジトリにインポートする必要があります。 つまり、RPMベースのディストリビューションを構築することは技術的な問題です。 Debianベースのディストリビューションでは、バックエンドの作成はもう少し複雑ですが、実現可能であり、すでに計画されています。 そして、派生ディストリビューションの作成と、複数のプラットフォーム用の1つのアプリケーションのアセンブリ-これらはすべて、少なくともやや複雑になります。
私は繰り返しますが、私たちはROSで長い間考案され開発された技術について話していて、最初は内部のニーズのために開発されました。 私たちはこれらの技術を引き継ぐように努力しませんでしたし、競争のために特別に準備しませんでした（そしてプロトタイプを準備する過程で、コードをいくつかの要件に緊急に適合させる必要があります）、さらに、ペンギンからのアプリケーションの予算は、これらの技術を開発するためにすでにかかった私たち自身の費用さえもカバーしません。 それでも、この契約で技術的な代替案の問題を提起する場合、当社の技術は参加に値し、重要なことには非常に近代的であると考えます（上記参照）。 申請するレベルは、LaunchpadとOBSレベルです。
納品後、プロジェクトをどのモードで実施するかという問題は未解決のままです。 もちろん、私たちはそれを開発し、特にDebianディストリビューション、Mandriva派生物（特に尊敬されているEduMandrivaチームに喜んでいます）、および他のハードウェアアーキテクチャでディストリビューションを構築するディストリビューションチームを招待することに興味があります。
エフゲニー・ソコロフ
ROSA R＆D