Re: glusterfs and hekafs release number for f16 and rawhide; systemd switch-over
On Mon, 2011-10-31 at 09:01 -0400, Kaleb S. KEITHLEY wrote: Up to now the glusterfs and hekafs versions and releases have been the same for f16 and rawhide, i.e.: glusterfs-3.2.4-1.x86_64.fc16.rpm, glusterfs-3.2.4-1.x86_64.fc17.rpm, hekafs-0.7-16.x86_64.fc16.rpm, and hekafs-0.7-16.x86_64.fc17.rpm. I did that because the source, thus far, is exactly the same for both f16 and rawhide. In f16 and rawhide both glusterfs and hekafs used sysv init.d scripts. Now for rawhide I'm going to switch to systemd. I know I can't switch to systemd for f16, so the question is, what scheme should I used for the release numbering? Honestly, I wouldn't fuss about keeping release numbers in sync - as soon as someone does the first Fedora 17 mass rebuild, they'll be out of sync anyway. Cheers, Mark. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: glusterfs and hekafs release number for f16 and rawhide; systemd switch-over
On Mon, Oct 31, 2011 at 09:01:33AM -0400, Kaleb S. KEITHLEY wrote: Up to now the glusterfs and hekafs versions and releases have been the same for f16 and rawhide, i.e.: glusterfs-3.2.4-1.x86_64.fc16.rpm, glusterfs-3.2.4-1.x86_64.fc17.rpm, hekafs-0.7-16.x86_64.fc16.rpm, and hekafs-0.7-16.x86_64.fc17.rpm. I did that because the source, thus far, is exactly the same for both f16 and rawhide. In f16 and rawhide both glusterfs and hekafs used sysv init.d scripts. Now for rawhide I'm going to switch to systemd. I know I can't switch to systemd for f16, so the question is, what scheme should I used for the release numbering? If you are planning only minor updates in F-16, you can probably use the description on Minor release bummps for old branches [1]. The result would than be something like: glusterfs-3.2.4-1.x86_64.fc16.rpm - base version with sysv-init glusterfs-3.2.4-2.x86_64.fc17.rpm - updated version with systemd-unit Bugfixes for F-16 can be done as patches/backports and the new nvr would be glusterfs-3.2.4-1.x86_64.fc16.1. For F-17/Rawhide it would just be in the new upstream version, or updated release as in glusterfs-3.2.4-3.x86_64.fc17. Personally I would favour this, but it will involve maintaining a seperate branch for the sysv-init version of the package. The main advantage is that the F-17/Rawhide spec will be kept simple, and there is no need to remove the %if statements once there is no sysv-init version available anymore. It will be impractical if you are planning big(ger) updates that would need a real version bump. Cheers, Niels [1] https://fedoraproject.org/wiki/Packaging:NamingGuidelines#Minor_release_bumps_for_old_branches -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
glusterfs and hekafs release number for f16 and rawhide; systemd switch-over
Up to now the glusterfs and hekafs versions and releases have been the same for f16 and rawhide, i.e.: glusterfs-3.2.4-1.x86_64.fc16.rpm, glusterfs-3.2.4-1.x86_64.fc17.rpm, hekafs-0.7-16.x86_64.fc16.rpm, and hekafs-0.7-16.x86_64.fc17.rpm. I did that because the source, thus far, is exactly the same for both f16 and rawhide. In f16 and rawhide both glusterfs and hekafs used sysv init.d scripts. Now for rawhide I'm going to switch to systemd. I know I can't switch to systemd for f16, so the question is, what scheme should I used for the release numbering? One thought I had was to 'leapfrog' increment the release numbers. I already have: glusterfs-3.2.4-1.x86_64.fc16.rpm and glusterfs-3.2.4-1.x86_64.fc17.rpm. Then for the systemd version then I'd go to glusterfs-3.2.4-2.x86_64.fc17.rpm. And if I need to respin glusterfs I'd use glusterfs-3.2.4-3.x86_64.fc16.rpm and glusterfs-3.2.4-4.x86_64.fc17.rpm. I.e: f16 rawhide current 3.2.4-1.fc16 [i] 3.2.4-1.fc17 [i] new... 3.2.4-2.fc17 [s] 3.2.4-3.fc16 [i] 3.2.4-4.fc17 [s] ([i] means init.d, [s] means systemd) Alternatively I could just add a character to the first release using sytsemd for rawhide, e.g. 's'. Then I'd have the existing glusterfs-3.2.4-1.x86_64.fc16.rpm and glusterfs-3.2.4-1.x86_64.fc17.rpm, and glusterfs-3.2.4-1s.x86_64.fc17.rpm for the new systemd version. And for a respin then I'd just use systemd going forward for rawhide, and I'd use glusterfs-3.2.4-2.x86_64.fc16.rpm and glusterfs-3.2.4-2.x86_64.fc17.rpm. I.e: f16 rawhide current 3.2.4-1.fc16 [i] 3.2.4-1.fc17 [i] new... 3.2.4-1s.fc17 [s] 3.2.4-2.fc16 [i] 3.2.4-2.fc17 [s] Whichever I go with I'd do the same thing for hekafs. Thoughts? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: glusterfs and hekafs release number for f16 and rawhide; systemd switch-over
On Mon, Oct 31, 2011 at 8:01 AM, Kaleb S. KEITHLEY kkeit...@redhat.com wrote:
Up to now the glusterfs and hekafs versions and releases have been the
same for f16 and rawhide, i.e.: glusterfs-3.2.4-1.x86_64.fc16.rpm,
glusterfs-3.2.4-1.x86_64.fc17.rpm, hekafs-0.7-16.x86_64.fc16.rpm, and
hekafs-0.7-16.x86_64.fc17.rpm.
I did that because the source, thus far, is exactly the same for both
f16 and rawhide. In f16 and rawhide both glusterfs and hekafs used sysv
init.d scripts.
Now for rawhide I'm going to switch to systemd. I know I can't switch to
systemd for f16, so the question is, what scheme should I used for the
release numbering?
Umm... Unless I don't understand your issue, which is possible since
I'm still working on coffee #2, you seem to be way over thinking this.
When I ran into this situation I just merged all the sysv and systemd
guidelines in the spec file and wrapped everything in %if 0%{?fedora}
... %endif statements.
For instance:
%if 0%{?fedora} 16
Requires(post): systemd-units
Requires(preun): systemd-units
Requires(postun): systemd-units
%else
Requires(post): chkconfig
Requires(preun): chkconfig
Requires(preun): initscripts
Requires(postun): initscripts
%endif
Then use the same logic for installing the service files, the
scriptlets, and in %files.
Richard
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
