I've tried to mostly stay out of this discussion because I to *NOT* consider myself an expert.
I've been a Fedora package maintainer for several years now and have learned more than I ever thought I would but I am not:
- a programmer
- an expert git user
- a *nix guru
From my simplistic point of view I basically have two workflows:
- An end user application which I keep updated to the same version across all supported Fedora releases (including EPEL where appropriate)
This obviously has the highest likelihood of having conditionals, especially with an EPEL branch. I pretty much feel the same as Kevin here. I merge all the branches, otherwise I have to fake upload sources multiple times, let it calculate the hash and figure out it's already uploaded which just seems silly, or maybe checkout "sources" from the master branch which I have learned how to do, but again, I'm not a git expert and to my knowledge this isn't documented.
The wiki even suggests the method Kevin and I use as the "proper" way...
- A library where I generally don't push major updates across branches (without a really good reason)
The best personal example I can think of is OpenImageIO, currently rawhide is on 1.8.x and Fedora 26 & 27 are on 1.7.x, and EPEL 7 is on 1.5.x, but was on the same series as Fedora a few releases ago.
Here I only fast-forward merge across branches on the same series/ABI version, but in the past it included EPEL which means you're more likely to carry "%if %{rhel}" type conditionals.
If you want packagers (especially those like myself that aren't in IT for $DAYJOB) to act differently, then the best way is to make sure the workflow is well documented and that it's the path of least resistance.
As far as obsolete conditionals, I don't personally proactively scrub my spec files until an update is needed. Here it's would probably be best to create some automated detection and file a BZ against the package. Maybe conditionals for Fedora versions N-2 (some people choose to support the most recently EOL'd version for a little while) and EOL'd EL releases.
Thanks,
Richard
_______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
