Bug 1053149

Summary: subversion package installs content into volatile /run directory
Product: [Fedora] Fedora Reporter: Jaromír Cápík <jcapik>
Component: subversionAssignee: Joe Orton <jorton>
Status: CLOSED NOTABUG QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: rawhideCC: jcapik, jorton, ovasik, vanmeeuwen+fedora
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2014-03-03 15:46:24 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Jaromír Cápík 2014-01-14 18:30:37 UTC
Description of problem:
Hello. As /run is mounted as tmpfs, the content is erased with each reboot and therefore it doesn't make sense to install anything into that directory.

The following packages need to be fixed ...

$ repoquery --whatprovides /run/*
lvm2-0:2.02.104-2.fc21.x86_64
cyrus-sasl-0:2.1.26-15.fc21.i686
cyrus-sasl-0:2.1.26-15.fc21.x86_64
subversion-0:1.8.5-3.fc21.i686
subversion-0:1.8.5-3.fc21.x86_64

Comment 1 Jaromír Cápík 2014-01-14 20:30:06 UTC
The following one should probably be ghosted ...

%attr(0700,root,root) %dir /run/svnserve

Comment 2 Cristian Ciupitu 2014-01-26 14:34:13 UTC
By the way, bug #1048422 is also about /run/svnserve.

Comment 3 Jaromír Cápík 2014-01-30 16:27:03 UTC
NOTE: If the directory is needed in between the installation and the consequent reboot, then it's better to create it with proper rights in the %post section. Anyway it's up to you to decide how to deal with this report. Closing as WONTFIX or NOTABUG is a solution too.

Comment 4 Joe Orton 2014-02-28 19:25:05 UTC
(In reply to Jaromír Cápík from comment #0)
> Hello. As /run is mounted as tmpfs, the content is erased with each reboot
> and therefore it doesn't make sense to install anything into that directory.

This is wrong.  This is why we have, and use tmpfiles.d.  What am I missing?

# cat /usr/lib/tmpfiles.d/svnserve.conf 
D /run/svnserve 0700 root root -
# rpm -qf /usr/lib/tmpfiles.d/svnserve.conf 
subversion-1.8.5-2.fc20.x86_64

Comment 5 Jaromír Cápík 2014-03-03 15:31:49 UTC
Hello Joe.

Sure, tmpfiles.d config files are supposed to re-create the directory after the reboot and till that happens, the directory needs to be created somehow, if needed in between the installation and reboot. I believe it isn't correct to create the directory the regular way so that it is included in the CPIO archive as in corner cases the CPIO content might be unpacked to a rootfs where tmpfs mountpoints are temporarilly missing/not mounted. This is a small gap in the guidelines and I believe the correct way is to create the directory as ghosted and call the following from the %post section:

systemd-tmpfiles --create %{_tmpfilesdir}/svnserve.conf

...anyway, I'll let you decide. Some of my reports were recently closed by the maintainers as NOTABUG and I don't have so strong urge to convince anyone to consider minor cases as there's a lot of other and more important stuff that needs fixing.

Cheers,
Jaromir.

Comment 6 Joe Orton 2014-03-03 15:46:24 UTC
The right way to go about this is to convince the FPC the current guidelines are wrong then, because packages today exactly follow the current docs.  I don't really understand the use-case, but adding a bunch of %post scripts is expensive, so there is a clear trade-off to be made.  Feel free to re-open if the guidelines change.