Dne 30.11.2017 v 16:15 Richard Shaw napsal(a):
On Thu, Nov 30, 2017 at 8:18 AM, Kevin Kofler <kevin.kofler@chello.at> wrote:
Vít Ondruch wrote:
> Apparently, there are two camps of packagers in Fedora/EPEL. Those who
> want:
>
> 1) single version of .spec file to cover the whole Red Hat ecosystem.
>
> 2) clean .spec file following the latest and greatest packaging practices.

I am actually inbetween: I want a single version of the .spec file to cover
all Fedora releases (and I care a lot about that, since I will push updates
to all releases if they do not contain any breaking changes that break user
expectations), but I do NOT want to support the ancient EL releases (which
is a pleonasm, i.e., even the most recent EL is ancient by Fedora
standards).

I pretty much fall into camp #1 as well. Most of the packages I maintain are end user applications and there's usually no reason to NOT update all supported releases of Fedora and EPEL, so my workflow is generally:

1. Update rawhide (pseudo branch "n") and make sure the build completes before doing any other builds.
2. fedpkg switch-branch <n-1>
3. git merge master

This is big and old-school hammer. If you did "git cherry-pick" instead, you could get most of the changes you did in master without the branches. Also, merging means that you get into older (or EPEL) branches stuff like changelogs from mass rebuild, which should not be there IMO.

You would be surprised, that by cherry-picking, I am able to get most of the Fedora changes into Red Hat Software Collections although the .spec files might differ in places significantly mainly due to SCL macros.


Vít

&& git push && fedpkg build --nowait
4. Wash / rinse / repeat 2 & 3 for each supported branch.

I also do the same for libraries for MINOR non-abi breaking releases.

Thanks,
Richard


_______________________________________________
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-leave@lists.fedoraproject.org