Bug 712173 - openSUSE:Tools/spec-cleaner: frivolous %{_initddir} breaks SLE_11_SP1
Summary: openSUSE:Tools/spec-cleaner: frivolous %{_initddir} breaks SLE_11_SP1
Status: RESOLVED WORKSFORME
Alias: None
Product: openSUSE.org
Classification: openSUSE
Component: 3rd party software (show other bugs)
Version: unspecified
Hardware: x86-64 openSUSE 11.4
: P5 - None : Normal with 1 vote (vote)
Target Milestone: ---
Assignee: Tomáš Chvátal
QA Contact: E-mail List
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-08-13 08:07 UTC by Christopher Yeleighton
Modified: 2015-04-20 09:02 UTC (History)
4 users (show)

See Also:
Found By: Community User
Services Priority:
Business Priority:
Blocker: ---
Marketing QA Status: ---
IT Deployment: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Christopher Yeleighton 2011-08-13 08:07:22 UTC
spec-cleaner replaces ‘/etc/init.d’ with ‘${_initddir}’; this breaks SLE_11_SP1 builds with the following message:

 cannot create regular file `/var/tmp/sysvinit-2.88+-build%{_initddir}/powerd'
Comment 1 Christopher Yeleighton 2011-08-13 08:09:03 UTC
spec-cleaner replaces ‘/etc/init.d’ with ‘%{_initddir}’
Comment 2 Vincent Untz 2013-10-21 12:54:59 UTC
Tomáš is reviving spec-cleaner at https://github.com/openSUSE/spec-cleaner so reassigning the bugs to him.
Comment 3 Tomas Cech 2014-01-26 21:31:35 UTC
%_initddir is not defined in SLE 11 SP1. But as a goal is to improve spec file quality in Factory I see proper solution to fix SLE in OBS, not spec-cleaner.
Comment 4 Tomas Cech 2014-02-09 21:41:20 UTC
Marcus, as one of members of autobuild-team group who maintains SUSE:SLE-11:* projects, what is your opinion here?
Comment 5 Marcus Rückert 2014-03-18 15:47:58 UTC
I think this question is more for the rpm maintainer and the maintenance team:

do we want to backport newer macros into sles 11 RPM and release it as update?

IMHO it is fine as long as we don't change existing macros. but adding new ones shouldn't break anything. we could put them into /etc/rpm/macros.backport

We could just do it inside the prjconf but then rebuilding with rpmbuild wouldnt work anymore.
Comment 6 Leonardo Chiquitto 2014-03-18 16:30:54 UTC
We can track this in our planned updates list and include the fix in the next update for 'rpm'.
Comment 8 Tomas Cech 2015-04-19 18:53:43 UTC
I'm not sure with the state but Tomas is now probably proper assignee.
Comment 9 Tomáš Chvátal 2015-04-20 09:02:56 UTC
This was fixed somewhere on the road. SP3 does not have this problem and all obs instances seems to build against it.

Closing for now unless you guys find another case where it is happening. Also currently prefferable method is to report issues over github.