On Thu, Oct 04, 2012 at 02:47:34PM -0400, Dave Reisner wrote:
On Thu, Oct 04, 2012 at 12:31:39PM -0600, Matthew Monaco wrote:
On 10/04/2012 12:27 PM, Tom Gundersen wrote:
On Thu, Oct 4, 2012 at 8:16 PM, Tom Gundersen <teg@jklm.no> wrote:
Hi guys,
Thanks to everyone who converted their packages to use native systemd service files since my last email.
There are stil 66 packages remaining in our TODO however (10 from extra and the rest from community): https://www.archlinux.org/todo/178/.
I got a request from a user eager to help to post the full list (our TODO lists are password protected, mostly by accident I think):
It's not password protected if you navigate to it from archlinux.org.
Is there a general strategy as far as reusing /etc/conf.d/? A lot of units can use those as environment files to work as drop-in replacements for the rc.d scripts, but there's probably more systemd-ish ways of configuring most units.
Environment files from /etc/conf.d are not to be used. We provide sane defaults in the unit file we ship (a conflation of the /etc/rc.d script and the options in the /etc/conf.d file) and let users override in /etc if needed.
d
Is there now any equivalent to .pacnew files for what would have been configuration files in /etc/conf.d? That is to say, if before a user edited /etc/conf.d/<some file> and that file received a newer version in its package, a .pacnew file would be left behind, indicating that the user should set about merging his/her custom configuration into the newer "stock" configuration. Very useful, that. Now, however, it would seem that the user will never see such a message (even though potentially critical changes have been made to the unit file) because the custom unit file in /etc/systemd/... won't be tracked by pacman. Is there a good solution for detecting such changes, so that users can once again merge their necessary changes into the systemd equivalents of /etc/conf.d files? -- David J. Haines djhaines@gmx.com