On 06/08/2018 11:54 AM, Ben Rosser wrote: >> you can ask Koji to build off the master branch for non-rawhide >> releases. > I actually didn't know this. Is this a recently added feature? Is > there some place I can read about it? I don't believe it is recently added, though I don't know Koji's history. I suspect it's been like this a long time though. I don't know it to be documented, I kinda just discovered it on my own. Basically, I noticed that "fedpkg build" really just calls Koji, and asks it to build a particular commit for a particular tag. For example, have a look at the "Source" field at: https://koji.fedoraproject.org/koji/buildinfo?buildID=1084812 It's git+https://src.fedoraproject.org/rpms/bodhi.git#9db03db15d7c9631887c759cc6bf19e0a1f4b241 That happens to be on Bodhi's master branch right now. So I could ask Koji to build that commit for f27 like this: $ koji build f27 git+https://src.fedoraproject.org/rpms/bodhi.git#9db03db15d7c9631887c759cc6bf19e0a1f4b241 You can also use branch names after the # in that URL, for example: $ koji build f27 git+https://src.fedoraproject.org/rpms/bodhi.git#master > My suspicion is that people are using "git merge" to bring changes to > other branches because a) people don't know they can just build from > master, and b) because various packaging tutorials [1] tell them to. I agree. However, I would continue to advocate taking advantage of the branches and using cherry picking to bring back specific changes to older releases. It really does help the spec file to be easier to read. Putting if statements in your spec file is like putting if statements in your code for what version of the code it is. I could have just a master branch for Bodhi's upstream code, and I could put if statements in it like: if bodhi_version > (3, 8, 0): # cool feature introduced in 3.8.0 here But I don't do that because I have and use git branches. When I fix a bug in master that I want to backport to an older release, I just git cherry pick. In my opinion, spec files are also just code and it makes sense to treat them the same way. > (I think this is actually a big problem in Fedora right now-- > infrastructure changes are happening faster than people are learning > to use the new infrastructure, which is making it really hard for > packagers to stay up to speed. It doesn't help that this stuff isn't > always communicated clearly.) Agreed. _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx/message/ETZKUTGC4JUVOYMYRGHALH3DPPJFGWQK/
