search

adapt-it / adaptit

Related language translation editor
Other
10 stars 5 forks source link

Add Github Actions workflow to build deb packages #63

Closed kanaka closed 2 years ago

alerque commented 2 years ago

I am not the project maintainer, but I am a prolific packager for several distros (primarily Arch Lunix, but also including maintaining some Debian/Ubuntu packaging). I strongly suggest that packaging stuff does not belong in the same repo as upstream projects. Debian stuff in particular is a problem, but the same goes for Arch PKGBUILD files etc. The release cadence for packaging is by definition out of sync with the upstream project (because it must come afterwards). It is frequently necessary to tweak packaging to adapt to distro issues and that should not need to trigger an upstream release affecting all other distros just to get one distro's packaging straightened out.

I suggest running another repository as an overlay with the debian directory and publishing from that. That gives you a lot more flexibility to deal with packaging without messing everyone else up. Also it keeps the access and expertise in the same place: upstream projects can't have packaging expertise on all dowstream distros. Even if they happen to have a contributor with Debian or Arch or Gentoo or SUSE or whatever expertise, they never have it all. Repos with distro specific packaging info are better maintained by people with that expertise directly, and the closer they are to the distro itself the better.

kanaka commented 2 years ago

@alerque [Full disclosure: I am @pngbill's son] Thanks for the feedback. I've done a fair bit of both project ownership and distro packaging (both open source and company internal). I don't think there is a universal single answer to this and it depends a lot on context and trade-offs (and can change over time). If there is tight coupling between project releases and package releases, then having separation can become overhead that isn't adding value. That coupling can be because of cadence, or technical details (tight integration/coupling with the distro may be a central feature), or project maintainer details (the people developing and packaging are one and the same), testing/CI requirements (the main go/no-go decision for a release of the project is whether the built packages install and work correctly on each distro), bug reporting (a high percentage of reported bugs have a strong packaging/distro component so project developers have to be aware of the details regardless), etc. In the case of AdaptIt, my sense is that a lot of the factors weight towards having the project and packaging files in the same repository. Certainly, when the trade-offs are different (i.e. true for most non-niche and very widely distributed open source packages), then there is greater friction/overhead from the coupling of having the packaging files in the same repo as the project.

It's also not that hard to split the packaging files into a separate repo in the future if @pngbill and the rest of the AdaptIt project team decide that's best (I occasionally consult but am not able to contribute regularly). It also doesn't have to be all or nothing. The packaging files for the primary targets of AdaptIt can be in the main repo and packaging files for other distros can be in another (or multiple other) repos. Are there some users/use cases you are aware of that are wanting to use AdaptIt but are limited by lack of packages for their particular distro they are running? Are you volunteering? :smile:

alerque commented 2 years ago

Thanks far the background. It does make some difference knowing there is a closer-than-random-drive-bycontributor relationship going on. I tend to still disagree about where the balance usually falls, but I respect at least some consideration of the pros and cons is involved.

Incidentally I take a position contrary to the documented "best practices" on a similar issue: namely GitHub recommends using a separate packaging repository to turn projects into Actions for use in CI runners whereas I think almost all the advantages are in having the packaging info for that in the same repo with the project (see e.g. how I setup luacheck, sile, and others for use as GitHub actions from the same repo as the projects).

Similarly for some containerization systems like Docker and stand alone distribution packages meant for use outside of a distro package manager or app store. It's just the distro packages that I feel strongly about being separated (e.g. I maintain a separate debian overlay repository and PPA builds for sile even though I am the upstream release manager and could just as easily embed the packaging).

And yes, the reason I have this project starred at all is because I was planning on setting up Arch Linux packaging for it.