Dne 30.11.2017 v 16:15 Richard Shaw napsal(a):
On Thu, Nov 30, 2017 at 8:18 AM, Kevin Kofler
<kevin.kofler(a)chello.at
<mailto: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(a)lists.fedoraproject.org
To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org