Gitea: Bintrayを介してリリースとdeb / rpmパッケージを提供する

本当にdeb / rpmが必要ですか？ Dockerイメージだけでは不十分ですか？ Idk、私が間違っていることを証明してください！ :)

ドローンにはDockerイメージしかありませんよね？

Gogsはpackager.ioを使用していますが、それを再利用してみませんか？

誰もがdockerを使用している/使用するわけではないからです。

Packager.ioはltsバージョンのみをサポートしますが、golangパッケージングは​​Packager.ioのオーバーヘッドよりもはるかに簡単に実行できます。

さて、私は囲碁について十分に知りません。 しかし、 https：//github.com/gogits/gogs/pull/3617がマージされなかったため、Ubuntu16.04のソリューションがあると便利です:(

ubuntu / debian / whateverバージョンのパッケージを提供するには、同じバイナリをパッケージにラップし、init（sysvinit、systemd）スクリプトを調整するだけです。

16.04 packager.io PRをマージして、当面の間、その上でgiteaを有効にすることはできますか？

バイナリとDockerの両方が必要です。

16.04 packager.io PRをマージして、当面の間、その上でgiteaを有効にすることはできますか？

まだ何も有効にしていませんが、この問題は1.0.0と推定されているので、最初のリリースで紹介したいと思います。

バイナリリリースも欲しいです-コンパイルするためのgo開発環境のセットアップがありません。

また、gogsからgiteaにアップグレードすることはできますか？ 私は自分の問題などを失うのは嫌だ。

バイナリリリースがあり、できれば主要なLinuxディストリビューション用のパッケージもあります。 何もコンパイルする必要はありません。

最新のマスターバージョンのバイナリもあります。

Gogsデータベースを使用してgiteaを直接起動できるようになります。 データベースが変更された場合、それらは自動的に移行されます。

ああ、すごいね！ 楽しみにしています☺

--Starbeamrainbowlabs（keybase.io/sbrl）

https://packagecloud.io （OSS — 25GBストレージ/ 250GB帯域幅+ CDN bintray.com 1TB / m）

@tboerger https://packagecloud.io/docs#os_distro_versionLTSおよび非LTSdeb / rpm / etc…
エレメンタリーOS / Raspbian / Ubuntu / Debian / SUSE Linux Enterprise Server / openSUSE / Fedora / LinuxMint / poky distro / Oracle Linux / Scientific Linux / Enterprise Linux（CentOS、RedHat、Amazon Linux）

@denjiええ私はpackagecloudを知っています、多分私たちはそれを取るでしょう、しかし私たちがそれのためにドローンプラグインを必要とするより:)

これは1.0.0では発生しないため、1.1.0に移動します。

Gogsはすでにdebとrpmパッケージを提供しているので、1.0.0で発生しないのであれば、これは本当に残念なことです。

Gogs0.9.99.0903をGitea1.1.0に問題なく更新できますか？

Gogsは、ltsバージョンのみをサポートし、奇妙なバイナリラッピングを行うサービスを使用しています。 私たちは本当の解決策を持ちたいと思っています。

Gogs0.9.99.0903からGitea1.1.0にアップグレードできると思います。

@tboergerこのようなことをするのはどうですか？ https://blog.codeship.com/using-docker-build-debian-packages/

@lunny @jhasseは、 apt-get upgradeによるアップグレードを意味すると思います

パッケージ名が異なるため、単純なapt-getアップグレードは機能しません。 しかし、apt-get remove gogs && apt-get installgiteaを実行することは機能すると思います:)

次に、Gogsのapp.iniをGiteaにコピーする必要があります。

次に、Gogsのapp.iniをGiteaにコピーする必要があります。

ただし、 apt-get install giteaの前にそれを行う必要があります。そうしないと、サービスがすでに開始されていることになります。

@jhasse IIRCのDebianパッケージングルールは、インストール時に自動有効化サービスを禁止しています：wink：

これを構成できます：http： //askubuntu.com/questions/365911/why-the-services-do-not-start-at-installation

そして、Ubuntuのデフォルトはそれらを自動有効にすることだと思います。 少なくともUbuntu14.04にGogsをインストールしたときは、手動でインストールする必要はありませんでした。

packager.ioがバイナリラッピングを行うのは事実ですが、gogs / giteaには必要です。 いくつかの環境変数を設定する必要があります。CentOS6gogsRPMのインストールと設定は非常に簡単です。
giteaにどのパッケージソリューションを選択する場合でも、インストール、構成、アップグレードが簡単であることを確認してください。

多くのパッケージは環境変数に依存していますが、それでもバイナリをラップする必要はありません。 そして、インストールと構成が簡単であることが常にパッケージの焦点であるかどうか？

だから私は実際にgiteaを.debにパッケージ化しています。 適切にパッケージ化されていないサーバーには何も許可しません。 現時点では、ちょっとしたパッチワークの仕事です（この＃480のせいもあります）。

アップグレードパスに関して... .debパッケージを使用すると、一部のファイルを「構成」ファイルとして宣言できます。これにより、パッケージマネージャーは次のようになります。

• パッケージをアンインストールした後、ユーザーがパッケージを明示的に「パージ」するまで保持します
• アップグレードで上書きする前に、変更を確認してください。 構成が変更された場合の対処方法をユーザーに尋ねます。

これにより、 .debにデフォルトのapp.iniファイルを含めることができます。このファイルには、コアのgiteaのデフォルトとは異なる一連のデフォルトが含まれています（例：＃480で説明したファイルパス）。

他のパッケージ（gogsなど）を廃止するメカニズムもありますが、gogsが.debなしでインストールされた場合、これはあまり役に立たない可能性があります。

私の設定コードをざっと見てみたい人はここにあります： https ：//github.com/couling/gitea/tree/dpkg-config/scripts/dpkg

まだオープンソースをスローしていない古いスクリプトを使用して（構成内のマニフェストファイルに基づいて）パッケージをビルドしますが、それが役立つ場合はすぐに実行できます。

@jhasse IIRCのDebianパッケージングルールは、インストール時に自動有効化サービスを禁止しています😉

それは面白い。 インストールすると、すべてのサーバーパッケージ（apache2などを含む）がサービスを開始しました。

@coulingはPRを送ってもらえますか？

@tboerger更新はありますか？

私の側からこれまでのところ更新はありません。 私見では、さまざまなDockerコンテナーを実行して、ターゲットOSと適切に一致していることを確認する必要があります（glibcの問題を参照）。 それに加えて、Dockerワークフローでは、ビルドチェーンではまだサポートできないため、32ビットシステムやその他のアーキテクチャは除外されています。

では、これをv1.2に入れましょう。

これが役立つかどうかはわかりません。 しかし、debianをまったく使用せずにDebianパッケージを作成するための実験的なGolang lib / toolがあります（ネイティブgolangのみ）。 また、「クロスプラットフォーム」の方法でDebianのパッケージを作成するときにいくつかの「問題」があり、dpkgビルダーの大ファンではありません。 ご覧ください： https ：//github.com/xor-gate/debpkg

まだ実験段階ですが、インストール可能なパッケージを生成することができます。

@ xor-gateありがとう、私がこの問題に戻ったときに見ていきます。

私はDebian用のGiteaのパッケージ化に挑戦するつもりでしたが、他の誰かが私を殴打したのを目にします-Debian Bug79210を参照してください。

@mjturnerこれは、これまでのところ私にとって5か月のプロジェクトであり、現在のレートでは、少なくともそれよりずっと長くなっています。 仕事の大部分はそれほど悪くはありませんが、私は進歩する能力を完全に破壊しているいくつかの重要な場所で立ち往生しています。

現在Debianにパッケージ化されていないすべてのgitea依存関係のパッケージ説明を書くのに最も助けが必要です。 私のGolangスキルは弱く、これらの部門の多くは彼らが何をしているのかについてほとんどまたはまったく説明がないため、これは私の時間の少なくとも80％を消費しています。 私はまた、いくつかのdebianビルドのものと戦ってきました。

あなた、または他の誰かが1.debianをインストールする2.apt-get install giteaを希望する場合は、私に手を差し伸べたいので、遠慮なくIRCに連絡してください。 MTecknology @ Freenode / OFTC

@MTecknologyあなたはそれに私を打ち負かしました-私はあなたに電子メールを送り、私が何らかの形で助けることができるかどうか見るつもりでした。 私はかなりの量のDebianパッケージングの経験があります（私は開発者の名誉です）が、Goアプリケーションのパッケージ化の経験はなく、かなりの量のGo開発の経験があります。 間もなくIRC経由で連絡します

@mjturner私はあなたを怖がらせたようです！ それでも興味があれば、少し圧倒されるところにいるので、本当に手を使うことができます。
または..他の誰か？ DebianのパッケージングやGoを理解している人はいますか？ かなりお願いしますか？...：cry：

こんにちは皆さん、Debianパッケージは非常に柔軟であるため、あまり直感的ではありません。 ほとんどの人は、.deb内のいくつかのファイルといくつかのメタ（パッケージ、バージョン、説明）が必要です。 最速の方法は、いくつかのフロントエンドツールを使用して単純なdebianパッケージを構築することだと思います。 例： https ：//github.com/laher/goxcまたはhttps://github.com/jordansissel/fpm。

Syncthing（golangプロジェクト）のメンバーは、FPMを使用してbuild.goスクリプトでdebianパッケージをビルドします。
https://github.com/syncthing/syncthing/blob/2579e8f7152c3205691f3798a81d43c1af4e8af6/build.go#L531 -L539

一部の人々はすでにdebianMakeビルドシステムにdh-make-golang （debianヘルパーがgolang用に作成）を持たせるためにいくらかの努力を払っています。https：//github.com/Debian/dh-make-golangを参照してください。

Debian用にパッケージ化するにはある程度の愛情が必要ですが、努力する価値はあります。

@MTecknology謝罪！ 私は間違いなく怖がっていません。数週間前の最後の連絡以来、Giteaに別の外観を与える機会がなかったので、他にもたくさんのものが溢れています:(

私の時間は今のところまだかなり限られていますが、私はまだ参加することに非常に熱心です。

心配ない。 このプロジェクトは、合理的で、正気で、よく調整された人がやろうとするべきもの以上のものです。 今のところ、ビルドは成功するが実行時の結果がセグメンテーション違反であるバージョンの非互換性に対処していると思います。 少なくとも、最終的にはポリシーに準拠したビルドになります。

パッケージ化された追加のjavascriptライブラリが必要であることがわかりました。 詳細... woohoo .....：sob：

@MTecknology現在のWIPパッケージを共有できる可能性はありますか（パブリックリポジトリなどを介して）？ 他の人を巻き込むことを奨励するのに役立つかもしれません。

@mjturner heheh ...あなたは実際に私のWIPへのリンクを投稿した場所へのリンクを投稿しました（Debianバグ）
-> https://github.com/MTecknology/gitea-wip/blob/master/work_in_progress

このスレッドに関する前回のコメント以降、大きな変更はありません。 私はなんとか実際のビルドを取得できましたが、それはsegfaultsです。 ライブラリのバージョンが一致していないために、segfaultsが原因であるというかなり堅実な予感があります。 私はほとんど（〜90）の新しいビルドデップがunstableに含まれていますが、何かを更新することを検討する前に、フリーズするまで待つ必要があります。 （すっごく）

現時点では、javascriptパッケージ/依存関係について最も助けが必要です。

これは、とりわけ＃1484によって延期される予定ですが、Debian 9がリリースされており、近い将来、再びいくつかの進歩を始める予定です。 やるべきことはまだたくさんありますが、いつかこの吸盤を閉めます！

こんにちは、fedora / centos / rhelでrpmを作成した人はいますか？

@ tboerger-私はあなたとあなたのチームがGiteaでやっていることが本当に大好きです！ GiteaがまだRPMを持っていないという人々の懸念に対処するために、RedHat派生ディストリビューション6.xおよび7.x用のGiteaRPMSを生成するツールを作成しました。 私はしばらくの間それをローカルでテストしてきました、そして私はそれを次の日か2日で本当にリリースすることに近づいています。

RPMSを構築するためのGOソリューションを探しているのか、RPMを構築するプロセスだけが必要なのかわからない。 私のツールは（ほとんどがPythonで書かれていますが）、Redhatのパッケージング標準に準拠するRPMSを生成します。

あなたがそのようなツールを使用することにオープンであるかどうかはわかりませんが、私は翌日か2日で私の公共のgitubを置くことを計画しています。

マージされていなくても、他の人に役立つ可能性がある場合でも、私たちは常にPRを受け入れています。 フォルダcontribを使用してスクリプトを保存できます。 全体的にはgolangを維持しようとしますが、特定のケースでは例外を作成し、Pythonが一般的なツールです。

@codylaneそれを楽しみにしています！ 私はfedoraパッケージング方法を使用してこれを行うことに取り組んでいましたが、それを行う方法がほとんどわからず、暗闇の中で撮影される予定でした。

すぐに、これが人々に役立つかもしれないと聞いてうれしいです。 readmeを完成させたところですが、今夜は公開githubアカウントに保存する必要があります。 リンクが利用可能になり次第共有します。

プルリクエストをgiteaに送信できれば幸いです。コミュニティが、リポジトリに入る前にそれが機能することを確認するのに役立つと考えました。 私はRPMの周りにたくさんの統合テストを持っていますが、それが機能することを確認する最良の方法は人々の前に立つことです。 :)

このような素晴らしいオープンソースツールを作成していただき、ありがとうございます。

たぶん、これはドローンプラグインの基礎となる作業でもあり、ドローン用のdebプラグインを作成した別の開発者とすでに話し合っています。

涼しい。 私もドローンをチェックアウトする必要があり、それは私の遊びのリストに載っています。

約束どおり、CentOS6および7用のGiteaRPMを構築するための自動CIプロセスがあります。https：//github.com/codylane/gitea-rpm。

ご不明な点やご不明な点がございましたら、お気軽にお問い合わせください。 私はすでにsystemdで1つの小さな問題を開いています。 明日直します。

Coprの使用について考えたことはありますか？

たぶん誰がPRを送ってドローンファイルを変更してdebを生成することができますか？ @tboerger @bkcsoft @appleboy

@jhasseは、オープンビルドサービスを使用することもできます。 これらのツールが最良の選択だとは思いません。

私はrpmとdebのためのドローンプラグインを好み、私たち自身またはbintray / packagecloudでリポジトリをホストします

@ tboerger-好奇心旺盛な私にドローンを突き刺してもらいたいですか？ 私が尋ねる理由は、自分のリポジトリをTravisCIに接続することを考えていたからです。 自己完結型のビルドサービスを好むかどうかは完全に理解しています。 :)

ドローンを調べてほしい場合は、チームがドローンをどのように使用しているかについてのドキュメントを共有できますか？ 私は標準に長けており、持っていない場合はホイールを再作成するのは好きではありません。

現在、私たちは主にdrone-plugins github orgのdrone寄稿者によって作成されたプラグインを使用しています。 @ thomasfはDebianベースのパッケージ用のdrone-debの構築を開始し、drone-pluginsorg内でdrone-rpmプラグインを開始したいと思います。

プロジェクトルート内に.drone.ymlが表示されます。これは、drone.gitea.ioでドローンインスタンスをホストしています。

涼しい。 このsystemdの問題を修正したら、推奨どおりに確認します。 ありがとう！

参考までに-systemdの問題は解決され、RPMは正常に機能しているはずです。 まだドローンのものを調べる必要があります。

Linuxでの「パッケージ」を介した簡単なインストール方法を提供するために別のアイデアを投入するだけです：http： //linuxbrew.sh。

こんにちは、debパッケージに関するニュースはありますか？ 私は本当にgiteadebパッケージが欲しいです;）
実際、Ubuntu16.04とUbuntu18.04には、もっと正確に言うと、それらが必要になります...

また、debianパッケージを作成し、この手順がこれまでに行われたことがない場合は利用できるようにします。お知らせください;）

この問題は、最近のアクティビティがないため、自動的に古いものとしてマークされています。 今後2週間以内にそれ以上の活動が発生しなければ、閉鎖されます。 貢献していただきありがとうございます。

stalebotにご協力いただきありがとうございます。

私はまだgithub.com/xor-gate/debpkggoパッケージをdebianパッケージ用に宣伝しています🎉 。

@ xor-gateは、contribにライブラリの構成ファイルを追加するためのPRを送信できますか？ ドローンプラグインでリリースできるかもしれません。

この問題は、最近のアクティビティがないため、自動的に古いものとしてマークされています。 今後2週間以内にそれ以上の活動が発生しなければ、閉鎖されます。 貢献していただきありがとうございます。

それに対する需要として考えてください...

解決策がないために古くなっただけです。

ギテアをパッケージ化しておくのに十分なエネルギーを持っている人はいないと思います
Debianメイン、典型的なgolangとの依存関係が多すぎます
生態系の問題[1]。 私はそれを作るために> 30時間/週で1年以上過ごしました
起こる; 私が諦めたとき、私はライブラリのために3ヶ月もかかりませんでした
の重大な変更により、Debianにプッシュされてアーカイブからプルされました
依存関係。

私は誰かがこれを非フリー（またはマゾヒスティックな場合はメイン）で維持するのを助けることができます
チームは自分自身を提示します）、しかしそれは不足についての警告を伴う必要があるでしょう
多くの理由で、安定性の。

[1]

• 一部のライブラリは、セキュリティバグがあり、機能していません。
• 多くのライブラリは、さまざまなレベルのメンテナンスでフォークされています（主に
  パッチして忘れる）
• 新しいライブラリは任意に追加され、多くの場合、レビューはほとんどまたはまったくありません。
• 'ベンダーに行く'（curl | sudo-）
• 200を超えるgolangdepsがリリースを提供することはめったにありません（アプリが常にリリースされることを期待しています）
  追加されたdepslibsを含め、最新のgitをプルします）

さらに-

• セキュリティ更新を調整する方法はないようです（
  更新することであなたを安全に保つという考え方...それは反対のことをします）
• > 2,000のjsライブラリと比較して、> 200のgolangライブラリは見劣りします
• 何が合法的に含まれることができるかについての懸念のひどい欠如があります
  オープンソースソフトウェア
• これらの問題を解決するための努力は、かなりの抵抗に見舞われてきました

気にしないディストリビューション用にgiteaをパッケージ化することは可能ですが
これらのライセンスと互換性の問題、私はそれを実現したときにあきらめました
全体のマゾヒストのチームなしではDebianメインで生き残ることはできません
最初のリリースだけでなく、多くの時間を利用できます。

繰り返しになりますが、興味のある方を喜んでお手伝いさせていただきますが、個人的には
これらの問題を取り除く、よりミニマルな「クローン」を作成します。 （遅い
時間がないので行く）
...誰かが私のプロジェクトまたはgiteaに取り組んでいることに興味があるなら
Debian、FreenodeのMTecknologyに連絡してください。

>>

@MTecknologyこの問題を解決するためのPRがあります。 https://github.com/go-gitea/gitea/pull/6671を参照してください。

私が言及した問題のいずれも解決しません。それは、Debianアーカイブにはまだ不適切な便利なパッケージにそれらすべてを導入するだけです。

そして、自動的にビルドされたDebianパッケージを提供するためにppa（私たちがホストする）を提供するのはどうですか？

JSライブラリはgitea自体にバンドルされると思っていたでしょう-私は、aptを介して利用できるいわゆるjavascriptライブラリのバージョンを常に避けてきました。これは、バージョンが何であるかを保証できないためです。

goライブラリに関しては、Giteaがリリースしたバイナリは1つだけだと思いましたか？ 少なくとも、それは私が使ってきたものです。 その単一のバイナリを含むパッケージを持つ単純なaptリポジトリを作成できませんか？

免責事項：私はDebianのメンテナではなく、.debファイルにパッケージ化した経験はかなり限られています。 私の経験はfpmまで続きます

@MTecknologyあなたは膨大な量の仕事をしましたが、残念ながら、debian用にgiteaをパッケージ化することは必ずしも意味がないように感じます。 プロジェクトには、Debianのリリースサイクルに一致するセキュリティまたはバグ修正を備えた古いバージョンをサポートするという目標はありません。 そして、あなたが言ったように、依存関係の量は管理できません。 囲碁の言葉「少しのコピーは少しの依存よりも優れています。」 無視されました。 ただし、依存関係を最新の状態に保つ、コピーしたコードをリファクタリングして必要なものだけを含めて修正をバックポートするなどのリソースがほとんどないボランティアの取り組みであるため、これも非常に理解できます。 そして、依存関係のJS / NPMの世界はさらに悪化しています。 giteaのようなソフトウェアは、いくつかのLinuxディストリビューションで動作するDockerイメージとして提供する方がよいと思います。 コードにはまだあなたが言及した依存関係とセキュリティ修正の問題があるので、うまくいけば、Dockerイメージはロックダウンされます。

yumリポジトリを提供すると、aptソースは別のものになり、インストールシェルスクリプトは別の選択肢になります。

もちろん、Debianまたはubuntuの公式リポジトリにgiteaを含めるのはクールですが、すでに上で述べたように、それは多くの作業をもたらします。

このようなパッケージングの悪夢を回避するために、bintrayを介して、またはcloudflarecdnによってサポートされるダウンロードミラー上のフォルダーを介して提供されるdebおよびrpmパッケージを作成するだけで済みます。

パッケージ自体はfpmを介して構築できます。または、誰かがドローンプラグインを提供します。これは、goで記述され、いくつかの標準を取得した場合、drone-plugins組織に到達する可能性もあります。 多くのfpm機能を実装したgoライブラリもあります。

配布用に正式にパッケージ化するという点では、それは長期的な目標である可能性があり、おそらくそうあるべきですが、現時点で必ずしもそうする必要はないと思います。 私たちのコードベースはまだ急速に変化しており、現時点では、これらのディストリビューションに正式にパッケージ化される非常に古いバージョンを維持することを約束することはできないと思います。

また、外部依存関係の数についても懸念しています。これらがハード依存関係（gorgeous、boltdbなど）として必要かどうか、および小さな依存関係の一部がフォークまたは書き換えられることでメリットが得られるかどうかを確実に検討する必要があります。 （マカロンセッションとgo-iniはどちらも問題のある私見です。）

また、goプラグインを実現するために、内部構造をリファクタリングする必要があります。 これにより、他のすべての依存関係を持ち込むことなくパッケージ化できる、よりスリムなコアgiteaを作成できると思います。

Goプロジェクトを適切にパッケージ化することは、PITAのすべてのディストリビューションにあります。 そのため、バイナリをビルドし、ディストリビューションのベストプラクティスを無視して、すべての依存関係を個別のパッケージとしてパッケージ化する単純なパッケージを提供する必要があります。

Debianのメンテナとして言えば、Debianにパッケージ自体としてgiteaがあると非常に素晴らしいでしょう。 ただし、技術的な（場合によってはライセンスに関する）問題があるため、これはこの問題の範囲外です。

Debianユーザーと言えば、debパッケージでgiteaを出荷するのはクールでしょう。 すでに静的なgoバイナリがあるので、その中に出荷できます。 これの進歩は、システムの起動時に開始するためのユニットファイルや、必要に応じて適切なデフォルト構成などの適切なインフラストラクチャを含めることもできるということです。
ほとんどのpplでは、パッケージソースを追加し、署名キーを追加して、パッケージをインストールすることを意味します。 更新は、ユーザーがすでに使い慣れている方法で展開されます。

CentOS rpm： https ：//cbs.centos.org/koji/buildinfo？buildID = 25894

頻繁に更新されるdnf / yumリポジトリにrpmを追加して、rpmディストリビューションユーザーがgiteaのセキュリティ更新などを簡単に最新の状態に保つことができるようにすると便利です。

@waja CentOSパッケージの変更がFedora用に更新され、テストされて安定している場合はEPELに追加される可能性がありますか？

これに関するニュースはありますか？ 1か月前、＃6671の@techknowlogickは、ドローンをrpmとdebsの自動ビルドに使用できると述べました。 誰かがそれを可能にする瞬間を見つけることができましたか？ もしそうなら、ドキュメントを更新していただけますか？

@Janhouse私はこれをFedora用にパッケージ化しようとしていますが、Goは適切にパッケージ化するのが面倒です。 上にリンクされているCentOSバージョンは、実際には適切にビルドされておらず、それに伴って発生する必要のあるいくつかの変更に気づきました。

パッケージがより適切に維持されることを保証するので、私はまだ適切な公式ビルドに興味があります。

@wajaは、プロジェクトを公式のdebainリポジトリに入れることについての口論を知りませんが、alpine-linuxにはすでに機能するパッケージがあります：ソース

公式のDebianリポジトリにgiteaを入れることはありません。これは、過去にすでに失敗した非常に大きな努力です。

ppaを維持するのはどれくらい難しいですか？

特に難しいことではありません、@ 6543。 実際、私はここに自分のaptリポジトリを持っています： https ：//apt.starbeamrainbowlabs.com/

私がそれを管理するために使用するコードはここで見つけることができます： https ：//git.starbeamrainbowlabs.com/sbrl/aptosaurus

誰かがGitHubからリリースファイルを自動的にダウンロードし、SHA256ハッシュを検証し、それらをfpmでパッケージ化するBashスクリプトを持っている場合は、自分で実行できれば幸いです（ただし、ホストできるかどうかはわかりませんが）以前のパッケージバージョン。Giteaは非常に大きく、ストレージスペースはすぐに増えます）。

パッケージの構築はドローンで行う必要があり、それよりも単にbintrayにアップロードする必要があります;）

@tboergerdebビルドスクリプトを使用してドラフトPRを作成してみます...
＆私たちはdl.gitea.ioを持っていますそこにもデブをアップロードする価値があります（そしておそらくリリース時のアタッチメントとして）

私は個人的にdebとrpmリポジトリを自分で管理したくないので、Bintrayはそのために最適です。 リポジトリなしでdebまたはrpmファイルをアップロードするだけでは、IMHOはまったく役に立ちません。

リポジトリなしでdebまたはrpmファイルをアップロードするだけでは、IMHOはまったく役に立ちません。

それは完全にナンセンスです！

debファイルとrpmファイルのビルドにnfpmを使用することもできます

誰かがすでにドローンfpmプラグインの構築を開始しています...私はまだgofpmフォークに基づいてプラグイン組織内でプラグインを構築したいと思っています。

これが私がnfpm用に作ったドローンプラグインです： https ：//github.com/techknowlogick/drone-nfpm

FHSシステム用のパッケージを作成する場合は、contribでシャドウイングスクリプトを使用するか、LDFLAGSを正しく設定してビルドすることを忘れないでください。

こんにちは、私は自分のAPTパッケージリポジトリを持っています。それにgiteaを追加できます。
すでに含まれているプロジェクトを参照してください： https ：//packages.azlux.fr/
これで実行中です。必要な.debを簡単に追加できます（作成することもできます）

アズラックス

@azluxそれはすべて信頼に帰着します。 あなたはおそらくかっこいい人ですが、プライベートリポジトリから取得するよりも、ビルドスクリプトがgitea開発チームによって維持されている既知の自動化サービスからインストールしたいと思います。 私も自分のパッケージを作成していますが、理想的にはgiteaチームによって管理されます。

針
情報をありがとう@Janhouse
repreproを使用してリポジトリを設定しました。必要に応じてサポートします。

Az

@Janhouse深く考えた後、aptリポジトリを使用すると、その間にソースが変更されていないことを確認できます。 理想的には、giteaが独自のリポジトリを維持することをお勧めしますが、他のリポジトリを「非公式リポジトリ」として配置することもできます。
多くのプロジェクトはそれで問題はありません。 そのように、人々は警告しました。

私は前にこれを言ったことを知っていますが...

Debパッケージを提供している場合は、次のようにLDFLAGSを設定して、FHSに準拠するようにGiteaをビルドする必要があります。

https://docs.gitea.io/en-us/install-from-source/#changing -the-default-custompath-customconf-and-appworkpath

ここでも同じです-私はホストできる個人的なaptリポジトリを持っています

また、giteaがFHS @zeripathをフォローすることを望んでいます。その愚かなことに、ラッパーシェルスクリプトも必要です。

それまでの間、RPMに関するニュースはありますか？ DEBについては多くの議論がありますが、多くの企業はDEBパッケージを使用しないCentOSを使用するでしょう。 BSDには独自のパッケージ（パッチ付き）があるようですが、プロセスは少し異なります。

@evitalis適切なLDFLAGSを使用してスクリプトを作成する場合、スクリプトは必要ありません。

私は知っている、私はこれさえ持っている彼らの必要性に言及していました。

考えてみてください。 FHSパスは、重大な変更が必要になるため、v2ではデフォルトにする必要があります。

それを少し分解する必要があると思います。 現在、ビルドには4種類あります。

• 開発ビルド-ソースをダウンロードし、makeでビルドします
• パーソナルビルド-ソースをダウンロードし、makeを使用してビルドしますが、これを実行中のサーバーにします
• リリースビルド-makereleaseを使用してビルドし、gitea.ioとGHに固執します
• Dockerビルド

FHSは、デフォルトで最大2つまで意味があります。リリースと場合によっては個人用ですが、現時点では、個人用ビルドが開発ビルドであるか、またはその逆であるかを判断できません。 開発ビルドを壊すことは非常に悪い考えです。

Dockerにはデフォルトも埋め込まれている必要があります。自分でビルドするDockerビルドでデフォルトで「-c」を要求する必要はありません。

バイナリが配置されている場所によっては、デフォルトで表示される場所が変わる可能性がありますが、それは悪い考えかもしれません。 私はこれの通常の習慣が何であるかをもう一度確認する必要があると思います。 （構成ルックアップの階層？-非常に複雑です）

私が最初にLDFLAGSオプションを機能させたとき、私は次のことを提案しました。

• FHSパスが埋め込まれた別のリリースを作成する
• Dockerにdockerのデフォルトパスを埋め込むようにします。これにより、dockerコマンドラインでgiteaを実行する際のその他の奇妙な問題がいくつか解決されます。
• フラグを適切に設定するFHSビルドのmakeエンドポイントを追加/公開します<-パッケージビルダーはこれを使用する必要があります...

これらは重大な変更ではなく、必ずしも2.0を待つ必要はありません。新しいダウンロードオプションを追加するだけです。

別の方法は、構成スクリプトを追加してインストールエンドポイントを作成することです。そうすると、以前は次のように「正常」に見えるようになります。

# get source by whatever means necessary
cd gitea
./configure
make
sudo make install

カスタムパスのフラグを指定しない場合、事前定義されたパス内で構成を検索するのは絶対に正常です。 これは、複数の標準パスを定義するためのhttps://github.com/spf13/viperの一部である例です。 Giteaの現在のめちゃくちゃな振る舞いはまったく珍しいものです。

おそらく、リリースビルドを最初にリポジトリに配置する価値があるのでしょうか。

@sbrlはすでに私のリポジトリで実行されており、ビルドスクリプトはここに保存されています： https ：//github.com/azlux/dpkg-deb
あなたが言ったように、それはリリースビルドを直接使用します。

@zeripathあなたはこれをあなたの返事に基づく必要があるよりも複雑にしていると思いますが、私はそれを誤解しているかもしれません。 人々がgit cloneを実行していて、自分で物を作っている場合は、問題が発生する可能性があることを知っておく必要があります。 masterブランチから上記のビルドを実行するか、リリースを使用する多くのプロジェクトでは、安定していると見なされますが、それ以外のものは安定しておらず、いつでも破損する可能性があります。

Dockerでも、FHSに従わない理由はないので、その場合もなくなります。 @tboergerが指摘しているように、残りの部分については、構成の標準パスセットをチェックすることは正常と見なされます。 ほとんどのユーザーには表示されない$ PWDまたはランダムコンパイルフラグのみに依存すると、OSのパッケージ化などの問題がさらに発生します。 いくつかのものをパッケージ化した人として、アプリケーションの標準性が低いほど、私にとってはより多くの作業が必要になり、より多くのパッチを導入する必要があります。

とはいえ、少なくとも公式のRPMを見ることにまだ興味があります。 私はDebianやUbuntuを使用していませんが、公式のDEBも歓迎されると確信しています。 このスレッドのすべての人に、暫定的にパッケージングに最善を尽くしてくれたことに感謝します。