On Mon, Nov 16, 2020 at 03:31:08PM -0500, Rob Crittenden wrote: > Zbigniew Jędrzejewski-Szmek wrote: > > On Mon, Nov 16, 2020 at 09:01:15AM -0800, Adam Williamson wrote: > >> On Mon, 2020-11-16 at 09:22 +0000, Zbigniew Jędrzejewski-Szmek wrote: > >>> > >>> (More generally: what would the point of keeping an "upstream" spec > >>> file be? > >> > >> One common reason is to integrate maintenance and testing with code > >> maintenance and testing, particularly to include package builds in CI > >> runs. > > > > That argument does sound somewhat reasonable, but I don't think it > > actually holds much water. > > > > Essentially, packages which do CI are packages which use modern build > > systems. And with the modern build systems the spec file doesn't need to > > be tweaked after each version bump. If a "modern" package needs the spec > > file to be constantly adjusted just to build than something is very wrong. > > > > I expect that the great majority of projects that do CI are just fine > > with using the "downstream" spec file, which can be easily pulled in > > from dist-git for the build. Doing this also has the obvious advantage > > that you can do CI on more than one downstream platform, using different > > spec files or debian control files or whatever arch has, as appropriate, > > without polluting the upstream repo with a dozen of downstream-specific > > build instructions. > > > > Buuuut, even if it turns out that it's easier to keep the spec file in > > upstream, the upstream can have copy of the spec file and that spec > > file can diverge from the Fedora version. All that needs to happen is > > that the changes are periodically synchronized (e.g. right before the > > version bump in Fedora). > > What you're missing with your "modern" build system argument is that the > spec doesn't have to "constantly" be updated, but it is often ahead of > downstream due to new files and dependencies. For rust, python, go, ... we're moving towards a system where build deps are expressed in package metadata. We're not there fully, but that's clearly the direction with %generate_buildrequires. For %files, most of the time we don't list most individual files either. Many packages list maybe a binary or two and the top-level package data directory. %license and %docs with relative paths takes care of the rest. > I can't speak for all maintainers but I do exactly what you propose: > re-sync before each downstream package release. Differences are > purposely kept to a minimum for this reason, so that diffs are easy to > understand to limit mistakes. > > My project uses an upstream spec file for CI exactly as Adam describes. OK, but than all's fine, no? You sync the changes, and the downstream spec file is still canonical, as far as other Fedora maintainers are concerned. I have no beef with using a spec file in the upstream repo for CI. I would do things differently myself, but that doesn't really matter. I'm only trying to push back against complaints about changes pushed to dist-git. The ability to have a canonical source for the spec file is crucial. And it's also crucial that this file is read-write, so that automated changes can be done across the distro. Zbyszek _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
