Provide deb/rpm and other packages for Gitea
- Dominant language
- Go
- Stars
- 58k
- Forks
- 7.1k
- Avg merge
- 1d 3h
- Merged PRs (30d)
- 178
Description
### 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_
Contributor guide
Assessment
This issue has not been assessed yet.