Tips on how to handle tmpfile changes

[Toshio Kuratomi]

On Wed, Dec 07, 2011 at 10:13:24AM -0600, Michael Cronenworth wrote:
> Paul Howarth wrote:
> > Simplest way is just to include the directory in the RPM in the same way
> > as you would if it was anywhere else in the filesystem. That caters for
> > operation immediately after installation, and the tmpfiles script can
> > re-create it on reboot.
> 
> The /run/vnstat directory must also be owned by the vnstat user since 
> vnstat no longer runs as root. I'll pass this along to the maintainer as 
> a solution.
> 
%files
%dir %attr(vnstat,vnstat,0755) /run/vnstat

or similar

> > Is it actually necessary to do this? The default pidfile location
> > appears to be /var/run/vnstat.pid and since on F15 /var/run is a symlink
> > to ../run, the pid file should end up in the right place by default,
> > should it not?
> 
> When the vnstat service attempts to start as the vnstat user it will be 
> unable to create /var/run/vnstat.pid (a.k.a. /run/vnstat.pid) and will exit.

Making config file changes is highly discouraged as you can't tell how your
scripted changes will interact with the random things that the end user may
have done to their config file.

You can punt on this, making the user add it manually (but then, the switch
to the way that vnstat.pid is created probably should not be pushed back to
released Fedoras and you should release note the change for when the user
upgrades to the Fedora where the switch happens).

You can write the script anyway, trying your best to anticipate all corner
cases.  Historically, this has been the case of numerous bugs but you may be
smart enough to avoid those/vnstat users may not have customized the config
in wild and wacky ways.

You can patch the code on that release to use the correct file/directory by
default.  This means you'll be carrying a local patch for a while -- unless
upstream can be convinced that a subdirectory is preferable to dropping the
file directly into the run dir.

None of these options are particularly attractive but the last one seems
like the least bad -- especially if upstream does take your patch.

-Toshio
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
Url : http://lists.fedoraproject.org/pipermail/devel/attachments/20111207/36926ab5/attachment.bin