Provide deb/rpm and other packages for Gitea #8183

New Issue

GiteaMirror · 2025-11-02T07:56:15-06:00

GiteaMirror commented

2025-11-02 07:56:15 -06:00

Originally created by @cmpunches on GitHub (Nov 28, 2021).

Feature Description

I am aware that this was filed early on in issue #31, but it seems to still be an issue.

There is a trend among some large project developers currently to erroneously believe that using container images or 3rd party packages (or even distributing precompiled binaries unpackaged!) is somehow a sane or appropriate workaround for compiling rpm or deb, which is easy, or negotiating a package pipeline with an interfacing os distribution.

In truth it reintroduces solved problems to the user's systems and promotes generally unsafe practices (one of which is installing software by means other than the system package manager in a professional environment). I realize that corporate contributors to major distros are curently advocating distribution models that rely on 3rd party package managers like snap, flatpak, appimage etc, or containers, or nothing at all, and these people are, in almost every case, incorrect for widely consumed projects that care about the maintenance of their product and those "worst practice" advocates' motives should be called into question.

Packaging is part of the SDLC. Distributing container images is not a workaround for distributing packages (images are good to distribute but should also rely on packages to facilitate the package's lifecycle -- install, update, remove -- it still starts with a package). Please don't make the mistake of thinking that containerization is a panacea as it is an architecture with specific use cases that this project really doesn't fit.

To not use native system packages is a regression, not an advancement, as neither 3rd party package managers nor container images can effectively manage system dependency trees or flexibly fit into all use cases for system administration, the most of obvious of which is that 3rd party package managers almost categorically do not interface with the default system package manager's database, which is almost gauranteed to create conflicts without careful tending. Some popular 3rd party package managers actually harm the systems they are installed on.

This used to be well understood but a few poorly behaving corporate projects have stained the culture a bit while creating bad precedents that are frequently cited in recent years due to the corporate promotion of developers who are highly skilled at creating software but have never had to learn systems administration to any depth due to the OS layer generally being handled by another team, and the only way I know how to address it is occasionally filing notices like this on projects I enjoy using and would like to see managed on the target systems better.

To people that did not drink that koolaid, distribution of non-packaged pre-compiled artifacts has the smell of using a gmail account for a company email inbox.

That said, thank you for listening to my rant, I hope you listen, and thank you very much for creating and maintaining a wonderful product, I see a great deal of potential with Gitea and I think alot of other people see that potential as well. I would also like to say that I'd be receptive to details on where I can donate to this project.

Screenshots

No response

Originally created by @cmpunches on GitHub (Nov 28, 2021). ### Feature Description I am aware that this was filed early on in issue #31, but it seems to still be an issue. There is a trend among some large project developers currently to erroneously believe that using container images or 3rd party packages (_or even distributing precompiled binaries unpackaged!_) is somehow a sane or appropriate workaround for compiling rpm or deb, which is easy, or negotiating a package pipeline with an interfacing os distribution. In truth it reintroduces solved problems to the user's systems and promotes generally unsafe practices (one of which is installing software by means other than the system package manager in a professional environment). I realize that corporate contributors to major distros are curently advocating distribution models that rely on 3rd party package managers like snap, flatpak, appimage etc, or containers, or nothing at all, and these people are, in almost every case, incorrect for widely consumed projects that care about the maintenance of their product and those "worst practice" advocates' motives should be called into question. Packaging is part of the SDLC. Distributing container images is not a workaround for distributing packages (images are good to distribute but should also rely on packages to facilitate the package's lifecycle -- install, update, remove -- it still starts with a package). Please don't make the mistake of thinking that containerization is a panacea as it is an architecture with specific use cases that this project really doesn't fit. To not use native system packages is a regression, not an advancement, as neither 3rd party package managers nor container images can effectively manage system dependency trees or flexibly fit into all use cases for system administration, the most of obvious of which is that 3rd party package managers almost categorically do not interface with the default system package manager's database, which is almost gauranteed to create conflicts without careful tending. Some popular 3rd party package managers actually harm the systems they are installed on. This used to be well understood but a few poorly behaving corporate projects have stained the culture a bit while creating bad precedents that are frequently cited in recent years due to the corporate promotion of developers who are highly skilled at creating software but have never had to learn systems administration to any depth due to the OS layer generally being handled by another team, and the only way I know how to address it is occasionally filing notices like this on projects I enjoy using and would like to see managed on the target systems better. To people that did not drink that koolaid, distribution of non-packaged pre-compiled artifacts has the smell of using a gmail account for a company email inbox. That said, thank you for listening to my rant, I hope you listen, and thank you very much for creating and maintaining a wonderful product, I see a great deal of potential with Gitea and I think alot of other people see that potential as well. I would also like to say that I'd be receptive to details on where I can donate to this project. ### Screenshots _No response_

GiteaMirror added the type/proposal label 2025-11-02 07:56:15 -06:00

GiteaMirror commented

2025-11-02 07:56:16 -06:00

@lafriks commented on GitHub (Nov 28, 2021):

Providing packages have been discussed before and I would not mind for us building them automatically but we need a way to easily integrate the process into our drone pipeline.

Donations can be made on https://opencollective.com/gitea

@lafriks commented on GitHub (Nov 28, 2021): Providing packages have been discussed before and I would not mind for us building them automatically but we need a way to easily integrate the process into our drone pipeline. Donations can be made on https://opencollective.com/gitea

GiteaMirror commented

2025-11-02 07:56:16 -06:00

@wxiaoguang commented on GitHub (Nov 28, 2021):

I agree that providing main stream packages is a good idea.

Some background for your information: Since Gitea is totally an open source and free project, the development of Gitea is mostly done by volunteers. If some volunteers have the motivation and the ability to implement a feature, then the feature may come. Otherwise, there are many good proposals pending because no volunteer has time to implement them.

@wxiaoguang commented on GitHub (Nov 28, 2021): I agree that providing main stream packages is a good idea. Some background for your information: Since Gitea is totally an open source and free project, the development of Gitea is mostly done by volunteers. If some volunteers have the motivation and the ability to implement a feature, then the feature may come. Otherwise, there are many good proposals pending because no volunteer has time to implement them.

GiteaMirror commented

2025-11-02 07:56:16 -06:00

@mscherer commented on GitHub (Nov 29, 2021):

For the record, there is a effort already to package gitea in Debian:
https://wiki.debian.org/Gitea

And there is a up to date Copr package for Fedora:
https://copr.fedorainfracloud.org/coprs/elxreno/gitea/

And one for Opensuse:
https://build.opensuse.org/package/show/devel:tools:scm/gitea

I am sure there is lots of others groups doing the packaging work, so maybe it would be better to join them.
Debian for example is waiting on some js dependencies to be packaged so gitea can move to main.

@mscherer commented on GitHub (Nov 29, 2021): For the record, there is a effort already to package gitea in Debian: https://wiki.debian.org/Gitea And there is a up to date Copr package for Fedora: https://copr.fedorainfracloud.org/coprs/elxreno/gitea/ And one for Opensuse: https://build.opensuse.org/package/show/devel:tools:scm/gitea I am sure there is lots of others groups doing the packaging work, so maybe it would be better to join them. Debian for example is waiting on some js dependencies to be packaged so gitea can move to main.

GiteaMirror commented

2025-11-02 07:56:17 -06:00

@cmpunches commented on GitHub (Nov 29, 2021):

Hey that's great news. So what about including these as official distribution channels in documentation?

@cmpunches commented on GitHub (Nov 29, 2021): Hey that's great news. So what about including these as official distribution channels in documentation?

GiteaMirror commented

2025-11-02 07:56:17 -06:00

@lammel commented on GitHub (Nov 29, 2021):

It might be a good idea to use goreleaser to be able to automatically create packages based on release tags (or snapshots).

We are using goreleaser to build rpm and deb packages and it is as easy as adding a single .goreleaser.yml file in the repo.
Can be used for CI/CD too a few lines of code.

If this is of interest I can work on a pull request to add this.

@lammel commented on GitHub (Nov 29, 2021): It might be a good idea to use [goreleaser](https://goreleaser.com) to be able to automatically create packages based on release tags (or snapshots). We are using goreleaser to build rpm and deb packages and it is as easy as adding a single .goreleaser.yml file in the repo. Can be used for CI/CD too a few lines of code. If this is of interest I can work on a pull request to add this.

GiteaMirror commented

2025-11-02 07:56:17 -06:00

@cmpunches commented on GitHub (Nov 30, 2021):

It might be a good idea to use goreleaser to be able to automatically create packages based on release tags (or snapshots).

The concept of having packages generated and added to package repositories on the end of a CI/CD pipeline is a good idea, but there are some considerations to make, pitfalls to avoid, and extra work to do with most popular options and configurations:

Want to avoid treating "RPMs as RPMs": For example, an RPM for Fedora is not interchangeable with an RPM from OpenSUSE or CentOS or derivatives of either. This goes for Debian vs. Ubuntu for DEBs etc.
The build environment must emulate the target environment for dependency tree alignment in mass distribution. For RPMs a best practice for building RPMs for mass distribution is to use a system like Mock to...well, "mock" the target environment. It covers most popular RPM-based distributions. I believe pbuilder is the DEB equivalent. This is a critical piece of the build environment for quality assurance. Alot of CI systems are built without this understanding baked into package generation features and generate a "local system compatible" package instead, which leads to frequent packaging issues . I'm unsure as to whether goreleaser has that awareness or not. What I've seen work well is a jenkins system for each target that watches the repo and in the case of an RPM, will build with a spec file and the source code to an SRPM file, which can be consumed by community package mantainers for mainstreaming the package in the OS-default repos, but a self-hosted repo works too as the right CI tools can generate the RPM (mock!). After package generation the CI system would need to place the rpm in a repo and update repo metadata if they opt to have "official package repositories". DEBs have similar considerations.
A decision would need to be made by the Gitea project on whether they want to:

A. Host the packages on their own "official gitea" repos. It's simple, it's easy to do, and saves alot of work. Alot of projects use a COPR and equivelant to do this. This has the great benefit of allowing all related products by the same project (as they come up) to be accessible after installing the "Official Gitea Repos". It would require at minimum VirtualHost directives to host the repositories, though, it probably should get its own dedicated host as a packages repository if you/they go the self-hosted route.

B. Integrate into the target distributions' base repos or extended repos (such as EPEL or RPMFusion). This would likely require package maintainers to maintain but provides much easier access by users of those distributions, and would be expected to increase popularity of the product a great deal. To clarify this requires at least one person maintaining the packages for one or more distributions.

C. Jam the packages on a file download directory like savages. Don't do this. It's always an option but it's a bad option and could attract time travelers showing up occasionally to try to stop you with matrix-esque kung fu moves and slow motion camera sweeps. Agent Smith wants you to do this. Don't do this.
Whatever decision is made in (3) needs appropriate infrastructure considerations and process, like repo hosting if they go with (A), or maintainers if someone volunteers for (B).
If a decision can be formalized around it, it should be integrated into the documentation.

@cmpunches commented on GitHub (Nov 30, 2021): > It might be a good idea to use [goreleaser](https://goreleaser.com) to be able to automatically create packages based on release tags (or snapshots). The concept of having packages generated and added to package repositories on the end of a CI/CD pipeline is a good idea, but there are some considerations to make, pitfalls to avoid, and extra work to do with most popular options and configurations: 1. Want to avoid treating "RPMs as RPMs": For example, an RPM for Fedora is not interchangeable with an RPM from OpenSUSE or CentOS or derivatives of either. This goes for Debian vs. Ubuntu for DEBs etc. 2. The build environment must emulate the target environment for dependency tree alignment in mass distribution. For RPMs a best practice for building RPMs for mass distribution is to use a system like Mock to...well, "mock" the target environment. It covers most popular RPM-based distributions. I believe pbuilder is the DEB equivalent. This is a critical piece of the build environment for quality assurance. Alot of CI systems are built without this understanding baked into package generation features and generate a "local system compatible" package instead, which leads to frequent packaging issues . I'm unsure as to whether goreleaser has that awareness or not. What I've seen work well is a jenkins system for each target that watches the repo and in the case of an RPM, will build with a spec file and the source code to an SRPM file, which can be consumed by community package mantainers for mainstreaming the package in the OS-default repos, but a self-hosted repo works too as the right CI tools can generate the RPM (mock!). After package generation the CI system would need to place the rpm in a repo and update repo metadata if they opt to have "official package repositories". DEBs have similar considerations. 3. A decision would need to be made by the Gitea project on whether they want to: A. **Host the packages on their own "official gitea" repos.** It's simple, it's easy to do, and saves alot of work. Alot of projects use a COPR and equivelant to do this. This has the great benefit of allowing all related products by the same project (as they come up) to be accessible after installing the "Official Gitea Repos". It would require at minimum VirtualHost directives to host the repositories, though, it probably should get its own dedicated host as a packages repository if you/they go the self-hosted route. B. **Integrate into the target distributions' base repos or extended repos (such as EPEL or RPMFusion).** This would likely require package maintainers to maintain but provides much easier access by users of those distributions, and would be expected to increase popularity of the product a great deal. To clarify this requires at least one person maintaining the packages for one or more distributions. C. **Jam the packages on a file download directory like _savages_.** Don't do this. It's always an option but it's a bad option and could attract time travelers showing up occasionally to try to stop you with matrix-esque kung fu moves and slow motion camera sweeps. Agent Smith wants you to do this. Don't do this. 4. Whatever decision is made in (3) needs appropriate infrastructure considerations and process, like repo hosting if they go with (A), or maintainers if someone volunteers for (B). 5. If a decision can be formalized around it, it should be integrated into the documentation.

GiteaMirror commented

2025-11-02 07:56:17 -06:00

@nmaludy commented on GitHub (Dec 13, 2023):

I'm looking to migrate from Gitlab -> Gitea. Having RPMs would be super helpful in my case, especially for patching and keeping up-to-date with security.

@lafriks You mentioned donations. What would the donation amount need to be to get this feature implemented?

@nmaludy commented on GitHub (Dec 13, 2023): I'm looking to migrate from Gitlab -> Gitea. Having RPMs would be super helpful in my case, especially for patching and keeping up-to-date with security. @lafriks You mentioned donations. What would the donation amount need to be to get this feature implemented?

Sign in to join this conversation.

Branches Tags

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/gitea#8183