Bug 784485

Summary:	Rpm needs better macro support for the sysvinit/upstart/systemd trinity
Product:	[Fedora] Fedora	Reporter:	Philip Prindeville <philipp>
Component:	systemd	Assignee:	systemd-maint
Status:	CLOSED NOTABUG	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	medium	Docs Contact:
Priority:	unspecified
Version:	16	CC:	ffesti, jnovy, johannbg, lnykryn, metherid, msekleta, notting, philipp, plautrba, pmatilai, systemd-maint, vpavlin
Target Milestone:	---
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2012-10-09 11:29:35 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:

Description Philip Prindeville 2012-01-25 05:05:53 UTC

Description of problem:

Writing .spec's for packages that, from a single version (e.g. all tracking 'master' or rawhide), build installation scripts for sysvinit, upstart, and systemd can get hairy (i.e. hard to read, hard to maintain, and error-prone).

Better encapsulation and macro shorthands for the respective sections would make .specs more compartmentalized and easier to read and maintain.

A good example of this is clamav's .spec file in rawhide/f16.


Version-Release number of selected component (if applicable):

4.9.1.2-1

How reproducible:


Steps to Reproduce:
1.
2.
3.
  
Actual results:


Expected results:


Additional info:

Comment 1 Panu Matilainen 2012-10-09 10:40:29 UTC

It's beyond rpm's scope to know details of all the software getting packaged with it, such macros need to be provided by systemd. In Fedora >= 18 systemd does provide helper macros for packaging tasks, but backporting to older versions is probably counter-productive at this point of eg F16 life cycle. That's up to systemd maintainer(s) though...

Comment 2 Michal Sekletar 2012-10-09 11:29:35 UTC

I'd argue that it's beyond systemd's scope to provide some generic macros covering all prior inits as well as systemd. Upstart and initscripts are obsolete anyway, so only init you need to support as of today is systemd, thus I don't know why anybody should care about prior init systems in Fedora.

Comment 3 Philip Prindeville 2012-10-09 16:17:54 UTC

(In reply to comment #2)
> I'd argue that it's beyond systemd's scope to provide some generic macros
> covering all prior inits as well as systemd. Upstart and initscripts are
> obsolete anyway, so only init you need to support as of today is systemd,
> thus I don't know why anybody should care about prior init systems in Fedora.

That ignores the fact that many packages that build for Fedora and EPEL are both synced to the same git version (master). EL6 is never going to be systemd based, yet a lot of services build out of the Fedora SCM.

Comment 4 Bill Nottingham 2012-10-10 02:43:39 UTC

If you are building from the same spec for both EL5, EL6, and F18/head, either you're just using sysvinit scripts, or your spec is already so conditionalized that a single macro won't help you. Unless I'm missing something?

Comment 5 Philip Prindeville 2012-10-10 05:49:35 UTC

(In reply to comment #4)
> If you are building from the same spec for both EL5, EL6, and F18/head,
> either you're just using sysvinit scripts, or your spec is already so
> conditionalized that a single macro won't help you. Unless I'm missing
> something?

Exactly. It's because the code IS so highly conditionalized that we're looking to clean it up with macros that simplify the various sysvinit- and systemd-specific sections... or at least bracket them in a more readable fashion.