Re: RFC: OpenRC as Init System for Debian
]] Stefan Fritsch For example, the apache2 init script starts htcacheclean if and only if mod_disk_cache is enabled. While this could arguably be considered as an upstrem deficiency, such cases won't simply disappear because systemd becomes more common. Ideally, they will, but even if they dont… And fixing this in the daemon as part of a packager's work is not feasible. ExecStartPre=some_script_that_checks_if_htcacheclean_is_needed_and_starts_it [...] Also, the apache2 init script creates various required directories on volatile file systems like /var/run or /var/lock and supports multiple running instances, but these are more common problems. tmpfiles.d for the directories, multiple instance support is built-in already, so that becomes easier if anything. -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87wr4c8w1t@qurzaw.varnish-software.com
Re: RFC: OpenRC as Init System for Debian
Josselin Mouette j...@debian.org writes: Le dimanche 13 mai 2012 à 20:00 +0200, Gergely Nagy a écrit : There is a huge difference between gconf, for which you can set one specific setting in /etc, overriding the default in /usr (and in a way that will not break the application if the schemas change), and systemd/udev, which require to copy the *entire* file, leaving behind any improvements that could made to it in ulterior versions. Not entirely true. You can override parts of the file too, without copying: include the original. This doesn't let you override everything, but for a lot of things, is good enough. And then, when the original file changes, you lose the improvements and you might even end up with a broken system. For example if a systemd unit file is updated to match a change of behavior in a daemon. Say, from now it requires a pre-exec stanza to do stuff it used to do at startup. Your modified file in /etc will not include this new stanza and your daemon is broken. Same problem exists with conf.d/ snippets. It's nothing unique to systemd, nor to etc-overrides-lib. If you can override, include or otherwise configure your system in such a way that you do not get warned when one part changes incompatibly, it will likely break, indeed. That is what NEWS.Debian can be used for, for example. But in systemd's case, there are better options, as discussed in this thread elsewhere (and from what I've been told, with a little bit of postinst magic, this can easily become a non-issue, but I haven't tested that yet). -- |8] -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87ipfwphgs.fsf@algernon.balabit
Re: RFC: OpenRC as Init System for Debian
Le dimanche 13 mai 2012 à 20:00 +0200, Gergely Nagy a écrit : There is a huge difference between gconf, for which you can set one specific setting in /etc, overriding the default in /usr (and in a way that will not break the application if the schemas change), and systemd/udev, which require to copy the *entire* file, leaving behind any improvements that could made to it in ulterior versions. Not entirely true. You can override parts of the file too, without copying: include the original. This doesn't let you override everything, but for a lot of things, is good enough. And then, when the original file changes, you lose the improvements and you might even end up with a broken system. For example if a systemd unit file is updated to match a change of behavior in a daemon. Say, from now it requires a pre-exec stanza to do stuff it used to do at startup. Your modified file in /etc will not include this new stanza and your daemon is broken. (And yes, this could be handled easily with a modified ucf, but currently it is not the case.) -- .''`. Josselin Mouette : :' : `. `' `- -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1337095592.3589.290.camel@pi0307572
Re: RFC: OpenRC as Init System for Debian
On Tue, May 15, 2012 at 05:26:32PM +0200, Josselin Mouette wrote: Le dimanche 13 mai 2012 à 20:00 +0200, Gergely Nagy a écrit : Not entirely true. You can override parts of the file too, without copying: include the original. This doesn't let you override everything, but for a lot of things, is good enough. And then, when the original file changes, you lose the improvements and you might even end up with a broken system. For example if a systemd unit file is updated to match a change of behavior in a daemon. Say, from now it requires a pre-exec stanza to do stuff it used to do at startup. Your modified file in /etc will not include this new stanza and your daemon is broken. Now I am confused. I thought this was the advantage of the include function of systemd. So, your etc-configuration file has as first line „:include lib-configuration file” and then your modifications. If a unit file is updated in /lib, you have the new stanza thanks to your include function. Of course this can still break the daemon, because your own changes couldn’t be valid anymore. The problem is that we seem to have three cases: - default configuration file is in /lib; if the daemon detects a file in /etc, it will read the file in /lib and then in /etc and merge the files together (which application does this?) - default configuration file is in /lib; if the daemon detects a file in /etc, it will only read the etc-file; thanks to the include support you can include the lib-file in the etc-file and only add the stanza you need (e.g. systemd) - default configuration file is in /lib; if the daemon detects a file in /etc, it will only read the etc-file; without include function you have to copy the complete lib-file to etc and edit it (e.g. udev) I don’t think we can force one of the cases as rule via policy, so the etc-directory should contain a README (e.g. in /etc/udev/rules.d) explaining how to change the default configuration. Shade and sweet water! Stephan -- | Stephan Seitz E-Mail: s...@fsing.rootsland.net | | Public Keys: http://fsing.rootsland.net/~stse/keys.html | smime.p7s Description: S/MIME cryptographic signature
Re: RFC: OpenRC as Init System for Debian
On Tue, May 15, 2012 at 05:26:32PM +0200, Josselin Mouette wrote: Le dimanche 13 mai 2012 à 20:00 +0200, Gergely Nagy a écrit : There is a huge difference between gconf, for which you can set one specific setting in /etc, overriding the default in /usr (and in a way that will not break the application if the schemas change), and systemd/udev, which require to copy the *entire* file, leaving behind any improvements that could made to it in ulterior versions. Not entirely true. You can override parts of the file too, without copying: include the original. This doesn't let you override everything, but for a lot of things, is good enough. And then, when the original file changes, you lose the improvements and you might even end up with a broken system. For example if a systemd unit file is updated to match a change of behavior in a daemon. Say, from now it requires a pre-exec stanza to do stuff it used to do at startup. Your modified file in /etc will not include this new stanza and your daemon is broken. (And yes, this could be handled easily with a modified ucf, but currently it is not the case.) Uhm, I think there's a misunderstanding here somewhere (or I'm misunderstanding your objection). The file in /etc *includes* the file in /lib. You don't copy them. The file in /lib is the unit file that gets updated, the file in /etc only contains overrides for the values you want to override. Thus, when /lib changes, those updates will be included, no breakage. The only issue I can think of is that there's currently (TTBOMK) no way of unsetting a value completely, which can cause issues if you want to override a setting that can take multiple statements. Regards: David -- /) David Weinehall t...@debian.org /) Rime on my window (\ // ~ // Diamond-white roses of fire // \) http://www.acc.umu.se/~tao/(/ Beautiful hoar-frost (/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120515163916.gh10...@suiko.acc.umu.se
Re: RFC: OpenRC as Init System for Debian
On Wednesday 09 May 2012, Gergely Nagy wrote: Apart from the fact that requirements will be different on different systems. Putting functionality for all possible corner cases into the daemon is not sensible for any upstream. That is what configuration files and similar things are for, I believe. I'd love to see an example where a complex init script is needed, and that can't be easily turned into systemd service files (for example). So far, I was told of two cases where the init script does more than a simple unit file does: one was nbd-client, which does funky stuff I dared not try to understand last night, the other is every package that supports starting multiple instances of the same service. For example, the apache2 init script starts htcacheclean if and only if mod_disk_cache is enabled. While this could arguably be considered as an upstrem deficiency, such cases won't simply disappear because systemd becomes more common. And fixing this in the daemon as part of a packager's work is not feasible. And with my upstream hat on, I would rather spend my time on fixing real bugs than things that can be easily worked around by the init script (or the apachectl script). Also, the apache2 init script creates various required directories on volatile file systems like /var/run or /var/lock and supports multiple running instances, but these are more common problems. The latter isn't hard to convert to systemd, and will even be simpler, as far as I see. And the integrator/packager may not want to learn all the funny languages that daemons can be written in (ocaml, haskell, java, ruby, ...). Besides, init scripts are conf files on Debian for good reasons. So are unit files and configuration files. If the daemon can't be configured and started properly without an init script's help, then something's very broken. Exceptions do exist, of course, but that falls under the 'absolutely necessary' label. I'd love to hear about examples though. If for nothing else, than to try my hands at making them work with systemd, it sounds like an amusing challenge. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201205152238.40909...@sfritsch.de
Re: RFC: OpenRC as Init System for Debian
On Tue, May 15, 2012 at 5:38 PM, Stefan Fritsch s...@sfritsch.de wrote: On Wednesday 09 May 2012, Gergely Nagy wrote: Apart from the fact that requirements will be different on different systems. Putting functionality for all possible corner cases into the daemon is not sensible for any upstream. That is what configuration files and similar things are for, I believe. I'd love to see an example where a complex init script is needed, and that can't be easily turned into systemd service files (for example). So far, I was told of two cases where the init script does more than a simple unit file does: one was nbd-client, which does funky stuff I dared not try to understand last night, the other is every package that supports starting multiple instances of the same service. For example, the apache2 init script starts htcacheclean if and only if mod_disk_cache is enabled. While this could arguably be considered as an upstrem deficiency, such cases won't simply disappear because systemd becomes more common. And fixing this in the daemon as part of a packager's work is not feasible. And with my upstream hat on, I would rather spend my time on fixing real bugs than things that can be easily worked around by the init script (or the apachectl script). Also, the apache2 init script creates various required directories on volatile file systems like /var/run or /var/lock Move this logic out of the init script and use ExecStartPre? That way the same logic can be used by all init systems. Please read systemd.service(5) if you haven't already. and supports multiple running instances, but these are more common problems. As far as I can tell, systemd supports multiple instances natively... Regards, -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/canvyna-oiacd2jvveuphlpvuqhsxzzv-jaosjnkqkxk7ldy...@mail.gmail.com
Re: RFC: OpenRC as Init System for Debian
Le vendredi 11 mai 2012 à 11:37 +0200, Tollef Fog Heen a écrit : I have /lib/systemd/system/foo.service and want to change something in it, I then create /etc/systemd/system/foo.service with a copy of the /lib one plus whatever changes I want. The version in /lib is then updated. How is the admin notified? The postinst script could run ucf but only if the file in /etc exists. It doesn’t seem very complicated to implement with existing tools. (Alternatively this could be an option to ucf.) -- .''`. Josselin Mouette : :' : `. `' `- -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1336919442.2522.2.camel@tomoe
Re: RFC: OpenRC as Init System for Debian
Le vendredi 11 mai 2012 à 11:25 +0200, Gergely Nagy a écrit : Thomas Goirand z...@debian.org writes: The fact that these files are in /lib and shouldn't be touched by the admin doesn't make them less configuration files. They still match the above definition from Wikipedia. Can I point you to /usr/share/glib-2.0/schemas/, /usr/share/gconf/defaults and similar? These are by the above definition, configuration files. Yet they are not under /etc. They are used to load the initial configuration of software, and can be overridden elsewhere (funny thing is, the gconf defaults can be overridden with stuff in /var/lib/gconf/debian.* - even the overides are outside of /etc!). Utterly wrong. The stuff in /var/lib/gconf is autogenerated, and any changes you do in it will not be preserved. The system administrator’s overrides have to be put in /etc/gconf. Can we fix these first, where not even the overrides are in /etc, let alone the defaults? Please? Can we get rid of useless babbling on debian-devel? Please? And in etc-overrides-lib, config files still remain in /etc. Its just the defaults that live elsewhere. That the defaults are files, and are under /lib, is an implementation detail, similarly how gconf defaults live under /usr/share/gconf/defaults. There is a huge difference between gconf, for which you can set one specific setting in /etc, overriding the default in /usr (and in a way that will not break the application if the schemas change), and systemd/udev, which require to copy the *entire* file, leaving behind any improvements that could made to it in ulterior versions. -- .''`. Josselin Mouette : :' : `. `' `- -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1336928648.2522.8.camel@tomoe
Re: RFC: OpenRC as Init System for Debian
Josselin Mouette j...@debian.org writes: Le vendredi 11 mai 2012 à 11:25 +0200, Gergely Nagy a écrit : Thomas Goirand z...@debian.org writes: The fact that these files are in /lib and shouldn't be touched by the admin doesn't make them less configuration files. They still match the above definition from Wikipedia. Can I point you to /usr/share/glib-2.0/schemas/, /usr/share/gconf/defaults and similar? These are by the above definition, configuration files. Yet they are not under /etc. They are used to load the initial configuration of software, and can be overridden elsewhere (funny thing is, the gconf defaults can be overridden with stuff in /var/lib/gconf/debian.* - even the overides are outside of /etc!). Utterly wrong. The stuff in /var/lib/gconf is autogenerated, and any changes you do in it will not be preserved. The system administrator’s overrides have to be put in /etc/gconf. Please read the by the above definition part. I know very well these are not configuration files, the same way /lib/systemd/system/ stuff isn't, either. I'm glad it can be overridden in /etc too, but that wasn't the point. Can we fix these first, where not even the overrides are in /etc, let alone the defaults? Please? Can we get rid of useless babbling on debian-devel? Please? Perhaps if you'd read what I was replying to, you would have noticed what I was attempting to do: show that how silly the configuration file definition quoted before was. And in etc-overrides-lib, config files still remain in /etc. Its just the defaults that live elsewhere. That the defaults are files, and are under /lib, is an implementation detail, similarly how gconf defaults live under /usr/share/gconf/defaults. There is a huge difference between gconf, for which you can set one specific setting in /etc, overriding the default in /usr (and in a way that will not break the application if the schemas change), and systemd/udev, which require to copy the *entire* file, leaving behind any improvements that could made to it in ulterior versions. Not entirely true. You can override parts of the file too, without copying: include the original. This doesn't let you override everything, but for a lot of things, is good enough. For the rest, well, it's a bit of inconvenience, but nothing that can't be fixed with a clever script to warn about the original files changing. -- |8] -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87y5ow3qs5@luthien.mhp
Re: RFC: OpenRC as Init System for Debian
Uoti Urpala uoti.urp...@pp1.inet.fi wrote: George Danchev wrote: [...] For some reason or another the vast majority of applications have not been following this approach. I'm not going to argue whether is makes sense or not. The reason why most old applications do not follow that approach (at least not yet) is pretty obvious: their authors never considered it. etc-overrides-lib semantics have only become a seriously considered alternative fairly recently. Having settings in one (optional) file overide settings in another one is far from being a new/fresh idea though. See pine. cu andreas -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/npi189-n4l@argenau.downhill.at.eu.org
Re: RFC: OpenRC as Init System for Debian
On 05/12/2012 01:34 AM, Jean-Christophe Dubacq wrote: I think it would be really great to have some program being able to output all manual differences to all /etc files really useful for maintenance. I used to do that, but some rapidly evolving configuration files make it quickly unmaintainable (php.ini comes to mind: I always have to put back the upload_max_filesize to a superior value, and this one-line difference makes something that should be really, really simple (upgrading php, even using stable+security) a pain because one gets manually prompted about the differences, even if they are trivial to merge. Yes, I truly agree with the above. We need something to handle changes better than what we have currently. Thomas -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4fae2952.3040...@debian.org
Re: RFC: OpenRC as Init System for Debian
On 05/12/2012 03:19 AM, Gergely Nagy wrote: The solution, however, is very simple: wrap dpkg calls, and have a list of files to watch for. Whenever a package touches a file that's on the list, fire a trigger, that can run a hook. Said hook can be something provided by etckeeper or similar, that would extract the appropriate file from the deb, and commit it to the upstream branch of /etc, for example. I like the idea of using Git. Because a new configuration file with new values would simply get merged with Git, who is quite smart about doing such merges. Only in complicated merge conflicts, we'd have to manually solve the issue. For such merge problems, it'd be great to simply pop a text editor so the user can decide how to solve the merge conflict. Thomas -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4fae2a10.8060...@debian.org
Re: RFC: OpenRC as Init System for Debian
On 05/12/2012 03:19 AM, Gergely Nagy wrote: It's perfectly able to notice changes in /lib/systemd too, or pretty much anywhere else. I thought these were only default which we shouldn't have to care about?!? :) Thomas -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4fae2a5c.6090...@debian.org
Re: RFC: OpenRC as Init System for Debian
On 05/12/2012 03:29 AM, Gergely Nagy wrote: It's not etc-overrides-lib that is the problem. It's defaults changing without notice that is. Then, let me ask this: Do you expect that systemd's default in /lib will change often? By the way, I finally found the time to try systemd, and I was shocked to see how fast it booted! :) The only thing is that I had no clue what started: nothing were prompted on my screen. Is there a way to have it more verbose? Thomas -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4fae2b7f.3000...@debian.org
Re: RFC: OpenRC as Init System for Debian
On 05/11/2012 05:07 PM, Gergely Nagy wrote: I'll turn this around: how do you handle cases where the defaults of packages like apt, exim or syslogd change? Where the defaults are embedded in the executable. The thing is, if you put the default in a file, it's because you expect these to change, at least more often than things that are compiled-in. Otherwise, what's the point in having stuff stored in a file that can be edited? Why not just do a .h with the values you need? Thomas P.S: I'm continuing to ask, even though you guys are slowly succeeding in convincing me... :) Not fully though... which is why I'm continuing this (I believe interesting) discussion. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4fae2ca5.8020...@debian.org
Re: RFC: OpenRC as Init System for Debian
Thomas Goirand z...@debian.org writes: On 05/12/2012 03:29 AM, Gergely Nagy wrote: It's not etc-overrides-lib that is the problem. It's defaults changing without notice that is. Then, let me ask this: Do you expect that systemd's default in /lib will change often? Nope. The only thing is that I had no clue what started: nothing were prompted on my screen. Is there a way to have it more verbose? If you remove 'quiet' from the kernel command line, yes. -- |8] -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87obpt8y4x@luthien.mhp
Re: RFC: OpenRC as Init System for Debian
Thomas Goirand z...@debian.org writes: On 05/12/2012 03:19 AM, Gergely Nagy wrote: It's perfectly able to notice changes in /lib/systemd too, or pretty much anywhere else. I thought these were only default which we shouldn't have to care about?!? :) You don't change defaults, but if you get notified when they do change, that's nice. I personally don't care, because there's only two things I override (syslog.service and media.mount), and I couldn't care less of the default in either case. :P But since there were a lot of but if it changes I get no notification!!!1! shoutings going on in here, I figured I'll mention that this solution is suitable for that notification purpose as well. It will notify you of all two cases that'll happen in the next year or two! :) -- |8] -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87havl8xy2@luthien.mhp
Re: RFC: OpenRC as Init System for Debian
On Sat, May 12, 2012 at 05:21:03PM +0800, Thomas Goirand wrote: By the way, I finally found the time to try systemd, and I was shocked to see how fast it booted! :) The only thing is that I had no clue what started: nothing were prompted on my screen. Is there a way to have it more verbose? This is probably better directed at a user-oriented list, or a systemd specific list. (Although I have seen the answer posted in this thread at least once.) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120512110535.GB30842@debian
Re: RFC: OpenRC as Init System for Debian
On 12.05.2012 11:21, Thomas Goirand wrote: By the way, I finally found the time to try systemd, and I was shocked to see how fast it booted! :) The only thing is that I had no clue what started: nothing were prompted on my screen. Is there a way to have it more verbose? 1/ Remove quiet from the kernel command line. This also has influence on the verbosity of the kernel itself. If you don't like the kernel message: 2/ Add systemd.sysv_console=true systemd.show_status=true to the kernel command line. man 1 systemd → KERNEL COMMAND LINE -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Re: RFC: OpenRC as Init System for Debian
On Sat, May 12, 2012 at 05:25:57PM +0800, Thomas Goirand wrote: On 05/11/2012 05:07 PM, Gergely Nagy wrote: I'll turn this around: how do you handle cases where the defaults of packages like apt, exim or syslogd change? Where the defaults are embedded in the executable. The thing is, if you put the default in a file, it's because you expect these to change, at least more often than things that are compiled-in. Otherwise, what's the point in having stuff stored in a file that can be edited? Why not just do a .h with the values you need? P.S: I'm continuing to ask, even though you guys are slowly succeeding in convincing me... :) Not fully though... which is why I'm continuing this (I believe interesting) discussion. At this point, I think all the pros and cons of all the various different strategies have been discussed ad nauseam--there's not much of value in continuing this further on this list. It's not adding anything new or useful. Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linuxhttp://people.debian.org/~rleigh/ `. `' schroot and sbuild http://alioth.debian.org/projects/buildd-tools `-GPG Public Key F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120512113200.gr23...@codelibre.net
Re: RFC: OpenRC as Init System for Debian
Thomas Goirand z...@debian.org writes: On 05/11/2012 05:07 PM, Gergely Nagy wrote: I'll turn this around: how do you handle cases where the defaults of packages like apt, exim or syslogd change? Where the defaults are embedded in the executable. The thing is, if you put the default in a file, it's because you expect these to change, at least more often than things that are compiled-in. Otherwise, what's the point in having stuff stored in a file that can be edited? Why not just do a .h with the values you need? The advantage of having the defaults in a file is that it makes it much easier to inspect them. A .h file would typically not be installed, so it wouldn't be readily available. In addition to that, it is much less expressive. The nice thing about storing the default values in the same format used by the configuration file is that if you find a default that you'd like to change, you immediately know what to put in the configuration file in order to change it. Best, -Nikolaus -- »Time flies like an arrow, fruit flies like a Banana.« PGP fingerprint: 5B93 61F8 4EA2 E279 ABF6 02CF A9AD B7F8 AE4E 425C -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87k40hh502@vostro.rath.org
Re: RFC: OpenRC as Init System for Debian
On 05/12/2012 10:02 PM, Nikolaus Rath wrote: The advantage of having the defaults in a file is that it makes it much easier to inspect them. A .h file would typically not be installed, so it wouldn't be readily available. In addition to that, it is much less expressive. The nice thing about storing the default values in the same format used by the configuration file is that if you find a default that you'd like to change, you immediately know what to put in the configuration file in order to change it. Then why not simply write this in /usr/share/doc/package/examples ? Thomas -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4faeb2b9.1080...@debian.org
Re: RFC: OpenRC as Init System for Debian
OoO Pendant le journal télévisé du samedi 12 mai 2012, vers 20:58, Thomas Goirand z...@debian.org disait : The advantage of having the defaults in a file is that it makes it much easier to inspect them. A .h file would typically not be installed, so it wouldn't be readily available. In addition to that, it is much less expressive. The nice thing about storing the default values in the same format used by the configuration file is that if you find a default that you'd like to change, you immediately know what to put in the configuration file in order to change it. Then why not simply write this in /usr/share/doc/package/examples ? Because they are the defaults of the application, not examples. This conversation is going nowhere. -- Vincent Bernat ☯ http://vincent.bernat.im /* Thanks to Rob `CmdrTaco' Malda for not influencing this code in any * way. */ 2.4.3 linux/net/core/netfilter.c pgppM9vVpexlQ.pgp Description: PGP signature
Re: etc-overrides-non-etc configuration file model [Re: RFC: OpenRC as Init System for Debian]
Don Armstrong d...@debian.org writes: On Thu, 10 May 2012, Gergely Nagy wrote: FWIW, /etc/default/* and /etc/$package/conf.d/* and similar already do something *very* close to what etc-overrides-non-etc does. To the point that changing a file under /etc/default, or adding a snippet to conf.d/ can break just as well when the underlying default changes as if that upstream happened to be outside of /etc. That's true. I suspect that much of conf.d/* and default/* are a consequence of the lack of easy 3-way merge support in dpkg. But that's kind of an orthogonal issue. I don't think that is so. It's also there to allow other packages to drop snippets there. Modifying another package's conffile would be against the policy, so conf.d/-style snippets are the obvious solution. Nothing to do with the lack of merge in this case. Even if dpkg gains fabulous merge support that never fails, ever, conf.d/ will still be used because we need the ability to add snippets from unrelated packages. Except it's easier to follow, since the default is never modified by the admin, while if it's in /etc too, like in plenty of cases in the archive, both can change, and we end up with even scarier situations that can't be resolved sanely. I'm unable to follow. In the etc-overrides-non-etc case, we would be increasing the number of cases where we had copies in /etc and in non-etc. If things were just in /etc, they wouldn't be in non-etc, and you'd only have one copy in all cases. True, if the non-etc stuff were simply copied, we'd have a single copy. With all the disadvantages that brings, like not being able to override the default from another package, as that would mean we have to modify a configuration file. In the case of systemd, you need to be able to override the default from another, unrelated package. At least for things like the syslog service. At the moment, systemd has /lib/systemd/system/syslog.service, which starts the journal. If I want to override that, I need to override the syslog.service, which is done by placing a file in /etc/systemd/system/syslog.service (whether a symlink, or a file, doesn't matter; the syslog daemons in debian place a symlink). If we didn't have etc-overrides-lib, how would you do this? How would you make it able to override a single service, from another package? Play dpkg-divert tricks? Or use conf.d/-style stuff? The latter suffers from the same issue etc-overrides-non-etc suffers from, the former makes it much harder for admins to override services, and I don't like the idea of dpkg-divert'ing config files all over the place either.. -- |8] -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/873977s1lq@luthien.mhp
Re: RFC: OpenRC as Init System for Debian
]] Uoti Urpala Hi, Wrong: as mentioned in this thread before, one of the advantages of the etc-overrides-lib model is the option of having a file in /etc that first includes the one in /lib, then overrides just one particular value. This allows handling more updates without needing manual changes, as you can automatically pick up other updated values while keeping the override, without needing to do 3-way merges. This doesn't always work, though. For instance, for systemd, you'd have no way to get rid of an ExecStartPre line, since you can have multiple of them. It's probably not that common, but it's a use case I want to support. Cheers, -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87vck3ns91@qurzaw.varnish-software.com
Re: RFC: OpenRC as Init System for Debian
OoO Pendant le journal télévisé du jeudi 10 mai 2012, vers 20:29, Jean-Christophe Dubacq jean-christophe.dub...@ens-lyon.org disait : I do not know about trivially merging changes in the etc-overrides-lib model, but in the current model, I am presented with the dpkg prompt about conffiles for some programs where I added (or changed) only one line (off the top of my head: only the servers list in roundcube, for example), and dpkg does not propose to merge the two files: I am either stuck with keeping my old file, taking the new, or using a shell. All these things are interactive and prevent unattended upgrades without disruption of services. roundcube uses ucf for its main configuration file and therefore, you should have a prompt with possibility to merge. -- Vincent Bernat ☯ http://vincent.bernat.im printk(KERN_WARNING %s: Short circuit detected on the lobe\n, dev-name); 2.4.0-test2 /usr/src/linux/drivers/net/tokenring/lanstreamer.c pgputTalXJ2N9.pgp Description: PGP signature
Re: RFC: OpenRC as Init System for Debian
On May 11, Nikolaus Rath nikol...@rath.org wrote: Wrong: since you have to copy the whole file to override it, and files in /lib have no conffiles handling, after an upgrade you will not know what was changed by you and what was changed upstream. I think everyone here agrees with that. The interesting case is when files in /etc/ can either explicitly include the /lib file, or implicitly override the /lib settings. I do not know about any package which work this way, but there is any then the problem is not different from packages which support multiple configuration file fragments in /etc, ship the default configuration in /etc and allow it to be modified by other configuration fragments in /etc (e.g. Apache). -- ciao, Marco signature.asc Description: Digital signature
Re: RFC: OpenRC as Init System for Debian
On Thu, 10 May 2012 21:30:56 +0300, Uoti Urpala uoti.urp...@pp1.inet.fi wrote: Marco d'Itri wrote: On May 10, Bjørn Mork bj...@mork.no wrote: Agree. Copying a large set of default policies into /etc just because they *can* be overridden is not user friendly. And it does not make the defaults any more configuration either. It just hides important local changes and makes it difficult both for the user and the application itself to distinguish between defaults and configuration overrides. Wrong: You're not addressing what he said about the generally desirable /etc semantics at all, only talking about what current Debian tools would do without modifications. Do you have a reason to oppose beyond this would need some tool changes? Yes -- it scatters configuration state outside /etc (thus hiding it from etckeeper and sysadmins alike), it makes the packages surprising to people familiar with Debian but not familiar with the package (Hint: we have a _lot_ of packages -- nobody is familiar with all of them. Requiring people to become familiar with all the packages before they can safely do an upgrade is part of what explains the number of rotting RedHat systems I see than nobody is brave enough to upgrade). since you have to copy the whole file to override it, Wrong: as mentioned in this thread before, one of the advantages of the etc-overrides-lib model is the option of having a file in /etc that first includes the one in /lib, then overrides just one particular value. This allows handling more updates without needing manual changes, as you can automatically pick up other updated values while keeping the override, without needing to do 3-way merges. This is the real problem with the etc-overrides-lib approach. For a sysadmin to know what to expect from a particular set of configuration files they need to be intimately familiar with the package in question, and why the change was made. Does the package allow partial overrides with includes or otherwise? Is the existence of an empty file deeply significant (think the udev persistent net thing). Did some default appear in lib that needs to be carried into etc? etc. etc. The traditional Debian approach to /etc is largely self documenting, to the extent that one can generally walk into a site cold and (having established that they have decent backups) cheerfully do an upgrade on their Debian servers without anything breaking (I do this regularly). The sources of potential breakage are highlighted by the packaging system, at which point you can read up on any package that needs attention with which you're not already familiar, while ignoring the ones that upgrade cleanly. Having exceptions to that is deeply unhelpful, and the more exceptions we accumulate the less maintainable and upgradable Debian becomes. Your assert that etc-overrides-lib is technically superior -- I and many others dispute that, but even if it were true, using that as a justification is equivalent to pointing out that driving on the left is safer[1] so Norway should make arrangements to allow visitors from the UK to drive on the left while the rest of the country continues on the right. When it's pointed out that that's a disastrous idea you respond by saying that all we need to do is fit some clever (as yet unbuilt) collision avoidance system to all the roads. Obviously this is not a problem for Red Hat since they do not support upgrades between major releases. Why would this cause problems for Debian, except at most needing some changes to tools to better support this case? Or do you think implementing that would be hard? Are you volunteering to do that? If not then stop making assertions that simply require someone else to do a load of work to pander to your unusual tastes. If you are volunteering, then that's somewhat better (although I would prefer that we simply fix the packages to behave themselves in a proper Debian way instead). Cheers, Phil. [1] see: https://en.wikipedia.org/wiki/Right-_and_left-hand_traffic#Safety_factors I believe Japan also did tests -- I don't really care if you disagree, just swap Left/Right and UK/Norway throughout the example and relax. -- |)| Philip Hands [+44 (0)20 8530 9560]http://www.hands.com/ |-| HANDS.COM Ltd.http://www.uk.debian.org/ |(| 10 Onslow Gardens, South Woodford, London E18 1NE ENGLAND pgp9a7nnyxdyw.pgp Description: PGP signature
Re: RFC: OpenRC as Init System for Debian
On 05/11/2012 12:53 AM, Uoti Urpala wrote: The reason why most old applications do not follow that approach (at least not yet) is pretty obvious: their authors never considered it. etc-overrides-lib semantics have only become a seriously considered alternative fairly recently. No. The reason is that we have FHS and the policy, so that packages *have* to behave the same way, and for very valid reasons which have been well described in this thread. You have absolutely everyone (this includes very experienced DDs) against your idea of changing a well established Debian policy, well written in the debian policy manual. Please stop. It's going nowhere. Thomas -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4faccc7d.3010...@debian.org
Re: RFC: OpenRC as Init System for Debian
On 05/11/2012 04:04 AM, David Weinehall wrote: On Fri, May 11, 2012 at 02:44:45AM +0800, Thomas Goirand wrote: On 05/10/2012 04:52 AM, Steve McIntyre wrote: No, really - please *do* do this. The fact that a lot of the software coming out of RedHat development seems to be designed solely for their use, including working around the missing/broken features of RPM, is seriously annoying. Configuration belongs in /etc, we know this. We have a well-designed and implemented set of tools in Debian based on that standard. I agree 100% with the above. On 05/10/2012 05:22 AM, Uoti Urpala wrote: Josh Triplett provided multiple technical reasons why etc-overrides-lib is preferable. The ONLY technical reason you gave to prefer traditional conffiles was that there already is a set of tools for that in Debian. No, it's because this way, I am warned by the package manager of a change on the default file, and I can merge by hand when I see it. Otherwise, you are silently changing the default, and potentially, I will miss the new options. Besides this, configuration files in /etc is written in the stones of our bible^Wpolicy-manual. Has anyone argued for having the configuration files anywhere else? It's all in the semantics of course, but to me, the configuration files are the files that the administrator changes to change a configuration. The files that go in /lib are the defaults. If the admin wants to override something they do so in /etc, just like before. From: http://en.wikipedia.org/wiki/Configuration_file In computing, configuration files, or config files configure the initial settings for some computer programs. They are used for user applications, server processes and operating system settings. The fact that these files are in /lib and shouldn't be touched by the admin doesn't make them less configuration files. They still match the above definition from Wikipedia. If the old file in /lib isn't equal to the new file being installed to /lib, and there's a user supplied file in /etc rather than just the default (which would only include the version in lib), then prompt the user. If the user is running a non-interactive upgrade, fire off an e-mail or something. For any major changes to the /lib files (stuff that are likely to trigger user actions), NEWS.Debian should of course, as usual, contain a heads up. No need to explain again, again and again the same thing. We did understand what your point is, but still, we don't agree with you and Uoti. Move on. Just because something isn't supported currently in our tools doesn't make it impossible to support it. The very reason why our tools don't support it, is because *we don't want it*. It's designed like this on purpose, and we are happy with the way things are right now. Why can't you implement something like amavis, grub2, or apache are doing? Especially Amavis, where the default config is a conffile, but you can override what you need by using a higher number in the file name. It works well, it is integrated with Debian and the way things work... And debian-policy isn't set in stone. Otherwise it wouldn't have last been revised in February 2012 :) The debian-policy maybe, but the FHS, and config files in /etc *is* a very strong policy that you will not change in Debian, and for very valid reasons already described in this thread. Thomas -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4facd03a@debian.org
Re: RFC: OpenRC as Init System for Debian
Thomas Goirand z...@debian.org writes: On 05/11/2012 12:53 AM, Uoti Urpala wrote: The reason why most old applications do not follow that approach (at least not yet) is pretty obvious: their authors never considered it. etc-overrides-lib semantics have only become a seriously considered alternative fairly recently. No. The reason is that we have FHS and the policy, so that packages *have* to behave the same way, and for very valid reasons which have been well described in this thread. Neither the FHS, nor the policy says anything about etc-overrides-lib as far as I can see. Neither pro or con. Do feel free to point me to the relevant section, would I be mistaken. The stuff in /lib are package defaults. Where the default is, in the program, embedded, or in some file, doesn't really matter, it's an implementation detail. Overrides (ie, configuration) *is* in /etc, as mandated by policy. You have absolutely everyone (this includes very experienced DDs) against your idea of changing a well established Debian policy, well written in the debian policy manual. Please stop. It's going nowhere. Erm, no. It's not written in the debian policy for a start, and not everyone agrees that etc-overrides-lib is a bad idea. I for one think it's a good idea in selected cases (systemd being one such), and no worse - in some ways, even better - than some other existing practice (the conf.d/ stuff I mentioned a few times elsewhere in this thread already). -- |8] -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87wr4jumk6.fsf@algernon.balabit
Re: RFC: OpenRC as Init System for Debian
Tollef Fog Heen tfh...@err.no writes: ]] Uoti Urpala Hi, Wrong: as mentioned in this thread before, one of the advantages of the etc-overrides-lib model is the option of having a file in /etc that first includes the one in /lib, then overrides just one particular value. This allows handling more updates without needing manual changes, as you can automatically pick up other updated values while keeping the override, without needing to do 3-way merges. This doesn't always work, though. For instance, for systemd, you'd have no way to get rid of an ExecStartPre line, since you can have multiple of them. It's probably not that common, but it's a use case I want to support. In that case, the including file can be changed (by the admin) to be a separate file, that does not include, and get the usual conffile conflict dpkg prompt. -- |8] -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87sjf7umhf.fsf@algernon.balabit
Re: RFC: OpenRC as Init System for Debian
Philip Hands p...@hands.com writes: On Thu, 10 May 2012 21:30:56 +0300, Uoti Urpala uoti.urp...@pp1.inet.fi wrote: Marco d'Itri wrote: On May 10, Bjørn Mork bj...@mork.no wrote: Agree. Copying a large set of default policies into /etc just because they *can* be overridden is not user friendly. And it does not make the defaults any more configuration either. It just hides important local changes and makes it difficult both for the user and the application itself to distinguish between defaults and configuration overrides. Wrong: You're not addressing what he said about the generally desirable /etc semantics at all, only talking about what current Debian tools would do without modifications. Do you have a reason to oppose beyond this would need some tool changes? Yes -- it scatters configuration state outside /etc (thus hiding it from etckeeper and sysadmins alike), it makes the packages surprising to people familiar with Debian but not familiar with the package (Hint: we have a _lot_ of packages -- nobody is familiar with all of them. Requiring people to become familiar with all the packages before they can safely do an upgrade is part of what explains the number of rotting RedHat systems I see than nobody is brave enough to upgrade). I'll turn this around: how do you handle cases where the defaults of packages like apt, exim or syslogd change? Where the defaults are embedded in the executable. You don't. That systemd has the defaults in files under /lib is an implementation detail. It's no different than any other default other software comes with, except that this one is easier to see and notice when it changes: it's possible to craft a trigger that'd fire in those cases. It's not possible to do that for cases where the default is hidden, which is the case for the vast majority of software. Yet, I do not see anyone jumping on those, and demanding they move *all* their defaults to /etc. since you have to copy the whole file to override it, Wrong: as mentioned in this thread before, one of the advantages of the etc-overrides-lib model is the option of having a file in /etc that first includes the one in /lib, then overrides just one particular value. This allows handling more updates without needing manual changes, as you can automatically pick up other updated values while keeping the override, without needing to do 3-way merges. This is the real problem with the etc-overrides-lib approach. For a sysadmin to know what to expect from a particular set of configuration files they need to be intimately familiar with the package in question, and why the change was made. Does the package allow partial overrides with includes or otherwise? Is the existence of an empty file deeply significant (think the udev persistent net thing). Did some default appear in lib that needs to be carried into etc? etc. etc. The same could be said of various conf.d/-style hacks that plague the archive. Do snippets override the things they change, or do they get merged? One must be familiar with the particular program to figure it out. This problem exists in every piece of software that can be configured, and does not use a single monolithic configuration file. The traditional Debian approach to /etc is largely self documenting, to the extent that one can generally walk into a site cold and (having established that they have decent backups) cheerfully do an upgrade on their Debian servers without anything breaking (I do this regularly). I'm afraid my experience disagrees, see above: the conf.d/-style hacks vary between packages, and there is *no* common ground. Some override settings completely, some get merged, it largely depends not only on the package in question, but in the setting aswell: even within a package, some settings get merged, some get overwritten. Sometimes it is even an error to try and override parts of the main configuration within a snippet - and you can't tell that only by looking at the files. You have to know the software in question, and how its configuration works. etc-over-lib is no different to existing practice. The only difference is where the defaults live, nothing else. The sources of potential breakage are highlighted by the packaging system, at which point you can read up on any package that needs attention with which you're not already familiar, while ignoring the ones that upgrade cleanly. Like I said elsewhere in the thread: conf.d/-style snippets. They're widely used, show the same problems. etc-over-lib is no worse. Having exceptions to that is deeply unhelpful, and the more exceptions we accumulate the less maintainable and upgradable Debian becomes. etc-over-lib is no exception. It's configuration in /etc, that overrides or changes default. Like *every* other piece of configuration that is in /etc. Where the default is, doesn't matter. We *never* get notification when defaults change, unless the default
Re: RFC: OpenRC as Init System for Debian
]] Gergely Nagy Tollef Fog Heen tfh...@err.no writes: ]] Uoti Urpala Hi, Wrong: as mentioned in this thread before, one of the advantages of the etc-overrides-lib model is the option of having a file in /etc that first includes the one in /lib, then overrides just one particular value. This allows handling more updates without needing manual changes, as you can automatically pick up other updated values while keeping the override, without needing to do 3-way merges. This doesn't always work, though. For instance, for systemd, you'd have no way to get rid of an ExecStartPre line, since you can have multiple of them. It's probably not that common, but it's a use case I want to support. In that case, the including file can be changed (by the admin) to be a separate file, that does not include, and get the usual conffile conflict dpkg prompt. How would that work? I have /lib/systemd/system/foo.service and want to change something in it, I then create /etc/systemd/system/foo.service with a copy of the /lib one plus whatever changes I want. The version in /lib is then updated. How is the admin notified? (This is the problem I want to fix with some yet unwritten tool.) -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87k40jnjmv@qurzaw.varnish-software.com
Re: RFC: OpenRC as Init System for Debian
Thomas Goirand z...@debian.org writes: From: http://en.wikipedia.org/wiki/Configuration_file In computing, configuration files, or config files configure the initial settings for some computer programs. They are used for user applications, server processes and operating system settings. The fact that these files are in /lib and shouldn't be touched by the admin doesn't make them less configuration files. They still match the above definition from Wikipedia. Can I point you to /usr/share/glib-2.0/schemas/, /usr/share/gconf/defaults and similar? These are by the above definition, configuration files. Yet they are not under /etc. They are used to load the initial configuration of software, and can be overridden elsewhere (funny thing is, the gconf defaults can be overridden with stuff in /var/lib/gconf/debian.* - even the overides are outside of /etc!). Can we fix these first, where not even the overrides are in /etc, let alone the defaults? Please? Just because something isn't supported currently in our tools doesn't make it impossible to support it. The very reason why our tools don't support it, is because *we don't want it*. It's designed like this on purpose, and we are happy with the way things are right now. Are you happy with dropping a snippet into a conf.d/ directory, and your software breaking on an upgrade without notice? Because that can happen even now, with software that uses only /etc, and /etc alone for their configuration, without any kind of default anywhere else. Why can't you implement something like amavis, grub2, or apache are doing? Especially Amavis, where the default config is a conffile, but you can override what you need by using a higher number in the file name. It works well, it is integrated with Debian and the way things work... It certainly does not work all that well. We came to live with it over the years, is all. And debian-policy isn't set in stone. Otherwise it wouldn't have last been revised in February 2012 :) The debian-policy maybe, but the FHS, and config files in /etc *is* a very strong policy that you will not change in Debian, and for very valid reasons already described in this thread. And in etc-overrides-lib, config files still remain in /etc. Its just the defaults that live elsewhere. That the defaults are files, and are under /lib, is an implementation detail, similarly how gconf defaults live under /usr/share/gconf/defaults. FHS and Policy are obeyed. -- |8] -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87bolvul1l.fsf@algernon.balabit
Re: RFC: OpenRC as Init System for Debian
On May 11, Gergely Nagy alger...@balabit.hu wrote: And in etc-overrides-lib, config files still remain in /etc. Its just the defaults that live elsewhere. That the defaults are files, and are under /lib, is an implementation detail, similarly how gconf defaults live under /usr/share/gconf/defaults. This is not similar to how gconf works, because gconf allows you to only set the directives you need in the new file, while udev and systemd require copying the whole file from /lib. -- ciao, Marco signature.asc Description: Digital signature
Re: RFC: OpenRC as Init System for Debian
On Fri, May 11, 2012 at 10:52:25AM +0200, Gergely Nagy wrote: Neither the FHS, nor the policy says anything about etc-overrides-lib as far as I can see. Neither pro or con. Do feel free to point me to the relevant section, would I be mistaken. To be honest, I still don’t really understand what the files in lib are: - Are they configuration examples with all possible settings and their default values and the application works fine without these files? Then they should be in /usr/share/doc/package. - Or doesn’t the application start without these files? Then they are undoubtedly configuration files and according to FHS and Debian policy configuration files belong in /etc The stuff in /lib are package defaults. Where the default is, in the program, embedded, or in some file, doesn't really matter, it's an implementation detail. It does matter. In the end it is the same situation as the firmware problem. For the hardware it doesn’t matter if the firmware is placed in an EEPROM on the hardware or loaded from the FS by the driver. But for Debian and its policy it is a difference. So if you don’t want a default configuration from a file, because you don’t want to put a file in /etc, then you must compile the program with your default settings. worse - in some ways, even better - than some other existing practice (the conf.d/ stuff I mentioned a few times elsewhere in this thread already). I like conf.d. It makes things easier for e.g. rsyslog or sysctl. Shade and sweet water! Stephan -- | Stephan Seitz E-Mail: s...@fsing.rootsland.net | | Public Keys: http://fsing.rootsland.net/~stse/keys.html | smime.p7s Description: S/MIME cryptographic signature
Re: RFC: OpenRC as Init System for Debian
On Fri, May 11, 2012 at 11:25:10AM +0200, Gergely Nagy wrote: Are you happy with dropping a snippet into a conf.d/ directory, and your software breaking on an upgrade without notice? Because that can happen even now, with software that uses only /etc, and /etc alone for their configuration, without any kind of default anywhere else. Yes, because I know that something is wrong when it breaks. This is better than the software is working but not anymore as you expect. Shade and sweet water! Stephan -- | Stephan Seitz E-Mail: s...@fsing.rootsland.net | | Public Keys: http://fsing.rootsland.net/~stse/keys.html | smime.p7s Description: S/MIME cryptographic signature
Re: RFC: OpenRC as Init System for Debian
Tollef Fog Heen tfh...@err.no writes: ]] Gergely Nagy Tollef Fog Heen tfh...@err.no writes: ]] Uoti Urpala Hi, Wrong: as mentioned in this thread before, one of the advantages of the etc-overrides-lib model is the option of having a file in /etc that first includes the one in /lib, then overrides just one particular value. This allows handling more updates without needing manual changes, as you can automatically pick up other updated values while keeping the override, without needing to do 3-way merges. This doesn't always work, though. For instance, for systemd, you'd have no way to get rid of an ExecStartPre line, since you can have multiple of them. It's probably not that common, but it's a use case I want to support. In that case, the including file can be changed (by the admin) to be a separate file, that does not include, and get the usual conffile conflict dpkg prompt. How would that work? I have /lib/systemd/system/foo.service and want to change something in it, I then create /etc/systemd/system/foo.service with a copy of the /lib one plus whatever changes I want. The version in /lib is then updated. How is the admin notified? NEWS.Debian, like with any significant default change. Other than that, the best I can think of is keeping track of what version of the package a default changed in, and triggering something from preinst, when upgrading from a version that is older than the change. This however, requires a lot of manual work, might aswell shovel the whole thing from under /lib to /etc then, but then we still didn't solve the problem: suppose there is a unit file that supports starting multiple instances, by way of symlinking. I start to use this feature, I change nothing, just symlink files around. At some point, this feature gets removed, my upgrade succeeds, but my instances won't start anymore, and the best notification I have is something that scrolled by that a conffile was upgraded. In this case, we have a succesful upgrade resulting in a broken system, because a default changed, and the user was not adequately notified. Which gets us back to NEWS.Debian being the best solution. There simply are cases where no automatism can be clever enough. -- |8] -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/877gwjujxr.fsf@algernon.balabit
Re: RFC: OpenRC as Init System for Debian
On 11/05/2012 08:47, Vincent Bernat wrote: OoO Pendant le journal télévisé du jeudi 10 mai 2012, vers 20:29, Jean-Christophe Dubacq jean-christophe.dub...@ens-lyon.org disait : I do not know about trivially merging changes in the etc-overrides-lib model, but in the current model, I am presented with the dpkg prompt about conffiles for some programs where I added (or changed) only one line (off the top of my head: only the servers list in roundcube, for example), and dpkg does not propose to merge the two files: I am either stuck with keeping my old file, taking the new, or using a shell. All these things are interactive and prevent unattended upgrades without disruption of services. roundcube uses ucf for its main configuration file and therefore, you should have a prompt with possibility to merge. Never got it. But I can quote other (courier, for example). Even /etc/default/locale was updated (only to include a bunch of comments). Is it really necessary ? BTW, for standard workstations, there is less and less need to change things in /etc. My current quota is 1346 files in /etc for about 30 of them with local changes. This is quite a bad signal/noise ratio. If dpkg kept a copy of the original configuration file (to be retrieved at all times), it would be easier to spot local changes. I use etckeeper to do that, but it's a bit tiresome to isolate all local changes (I have to save the diffs somewhere) (and a lost hope if you do install etckeeper late in the workstation life). My git-fu is probably not good enough (I am probably looking for a pristine branch and a rebased local branch used in production). -- Jean-Christophe Dubacq signature.asc Description: OpenPGP digital signature
Re: RFC: OpenRC as Init System for Debian
On Fri, May 11, 2012 at 12:07:55PM +0200, Jean-Christophe Dubacq wrote: BTW, for standard workstations, there is less and less need to change things in /etc. My current quota is 1346 files in /etc for about 30 of them with local changes. This is quite a bad signal/noise ratio. Well, a standard workstation has many configuration changes I would say, but these changes are all user settings for their WM/DM or application configuration like pidgin or audacious that reside in /home/user. But if you don’t configure files in /etc, why is it a problem if you have many files in /etc? Shade and sweet water! Stephan -- | Stephan Seitz E-Mail: s...@fsing.rootsland.net | | Public Keys: http://fsing.rootsland.net/~stse/keys.html | signature.asc Description: Digital signature
Re: RFC: OpenRC as Init System for Debian
Stephan Seitz stse+deb...@fsing.rootsland.net writes: On Fri, May 11, 2012 at 11:25:10AM +0200, Gergely Nagy wrote: Are you happy with dropping a snippet into a conf.d/ directory, and your software breaking on an upgrade without notice? Because that can happen even now, with software that uses only /etc, and /etc alone for their configuration, without any kind of default anywhere else. Yes, because I know that something is wrong when it breaks. This is better than the software is working but not anymore as you expect. You do realize that the only difference between the two cases is that when the default happens to be in /etc, you get a Configuration file updated thing scroll by? Other than that, things break exactly the same way, and you will have no more information, and the one you have is of little use, as it happily overwrote the unmodified default, so you'll have to hunt down the former version anyway, to see the difference. -- |8] -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87vck3t483.fsf@algernon.balabit
Re: RFC: OpenRC as Init System for Debian
Jean-Christophe Dubacq wrote: If dpkg kept a copy of the original configuration file (to be retrieved at all times), it would be easier to spot local changes. I use etckeeper to do that, but it's a bit tiresome to isolate all local changes (I have to save the diffs somewhere) (and a lost hope if you do install etckeeper late in the workstation life). My git-fu is probably not good enough (I am probably looking for a pristine branch and a rebased local branch used in production). You might be interested in a proposal at UDS this week: https://blueprints.launchpad.net/ubuntu/+spec/foundations-q-dpkg-pristine-conffiles -- Steve McIntyre, Cambridge, UK.st...@einval.com You can't barbecue lettuce! -- Ellie Crane -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/e1ssnta-0007af...@mail.einval.com
Re: RFC: OpenRC as Init System for Debian
m...@linux.it (Marco d'Itri) writes: On May 11, Gergely Nagy alger...@balabit.hu wrote: And in etc-overrides-lib, config files still remain in /etc. Its just the defaults that live elsewhere. That the defaults are files, and are under /lib, is an implementation detail, similarly how gconf defaults live under /usr/share/gconf/defaults. This is not similar to how gconf works, because gconf allows you to only set the directives you need in the new file, while udev and systemd require copying the whole file from /lib. But by the wikipedia definition, the gconf defaults are config files too. My point was to make it clear that blindly following that definition might not lead to desirable results. But, a few more examples of config files, or snippets from directories different than /etc: * /usr/share/X11/xorg.conf.d/: I would especially like to quote these lines from the 50-synaptics.conf file from there: , | # DO NOT EDIT THIS FILE, your distribution will likely overwrite | # it when updating. Copy (and rename) this file into | # /etc/X11/xorg.conf.d first. ` While said file also says it is an example, looking at xorg.conf.d(5), it suggests that X11 will behave somewhat similar to systemd, and search for override-able config snippets in directories outside of /etc. According to the manpage: When the same information is supplied in more than one way, the highest precedence mechanism is used. In other words, it does *exactly* the same thing systemd is criticised for. * /usr/share/alsa/alsa.conf.d/: Files herein will be processed by alsa-lib, according to the README. They are obviously config file snippets, and as such, if following the wikipedia definition, should be in /etc. I assume - though, haven't checked - that files in /etc can override these settings. I could probably find more, but just two off the top of my /usr/share seemed enough for now. It seems to me that etc-overrides-non-etc is already existing practice, if X11 and ALSA use it too, among others. In light of this, systemd is no different. It just has more defaults in files under /lib. Long story short, I still don't see what the fuss is about. -- |8] -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87obpvt313.fsf@algernon.balabit
Re: RFC: OpenRC as Init System for Debian
Stephan Seitz stse+deb...@fsing.rootsland.net writes: On Fri, May 11, 2012 at 10:52:25AM +0200, Gergely Nagy wrote: Neither the FHS, nor the policy says anything about etc-overrides-lib as far as I can see. Neither pro or con. Do feel free to point me to the relevant section, would I be mistaken. To be honest, I still don’t really understand what the files in lib are: - Are they configuration examples with all possible settings and their default values and the application works fine without these files? Then they should be in /usr/share/doc/package. They are default settings for a particular service, and the application does not work without them. - Or doesn’t the application start without these files? Then they are undoubtedly configuration files and according to FHS and Debian policy configuration files belong in /etc It is indeed true, that these are settings the application does not work without. So are many things under /usr/share, some of them similarly configuration files (/usr/share/X11/xorg.conf.d/; /usr/share/alsa/alsa.conf.d/ to name just two). That a default happens to be in a file does not make it a configuration file. A configuration file is something you *change* to alter a programs behaviour. With systemd, these files are under /etc. That the defaults are split out into separate files is an implementation detail, nothing more. You do *NOT* change the defaults. You change the settings. The stuff in /lib are package defaults. Where the default is, in the program, embedded, or in some file, doesn't really matter, it's an implementation detail. It does matter. In the end it is the same situation as the firmware problem. For the hardware it doesn’t matter if the firmware is placed in an EEPROM on the hardware or loaded from the FS by the driver. But for Debian and its policy it is a difference. Policy governs configuration. It never talks about default settings, it does not mandate anywhere where and how defaults are to be set. So if you don’t want a default configuration from a file, because you don’t want to put a file in /etc, then you must compile the program with your default settings. What happens if your defaults are open-ended? When you *can't* compile them all in, because third party packages are able to extend the set of default settings? You can't compile in the defaults in that case. You could compile in the subset shipped with the package, and you could make it so that third party packages only use stuff in /etc, but that would needlessly complicate matters for no real benefit. worse - in some ways, even better - than some other existing practice (the conf.d/ stuff I mentioned a few times elsewhere in this thread already). I like conf.d. It makes things easier for e.g. rsyslog or sysctl. They also suffer from the very same problem the defaults in /lib/systemd do. Namely, if you did not change the default, and it changes under you, your system can break without any kind of warning or notice, and very little trace as to what went wrong. -- |8] -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87k40jt2l2.fsf@algernon.balabit
Re: RFC: OpenRC as Init System for Debian
On 05/11/2012 04:52 PM, Gergely Nagy wrote: Neither the FHS, nor the policy says anything about etc-overrides-lib as far as I can see. Neither pro or con. Do feel free to point me to the relevant section, would I be mistaken. Section 10.7.2 of dpm: Any configuration files created or used by your package must reside in |/etc|. The policy never talks about etc-overrides-lib configuration files, it only tells that all configuration files should go in /etc, and there's no exception, and it is also a must. Thomas -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4facf2d8.5050...@debian.org
Re: RFC: OpenRC as Init System for Debian
On 05/11/2012 05:25 PM, Gergely Nagy wrote: And in etc-overrides-lib, config files still remain in /etc. No. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4facf398.2010...@debian.org
Re: RFC: OpenRC as Init System for Debian
On 05/11/2012 06:39 PM, Gergely Nagy wrote: In other words, it does *exactly* the same thing systemd is criticised for. Which doesn't mean that it's a good practice. Thomas -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4facf423.1090...@debian.org
Re: RFC: OpenRC as Init System for Debian
On 05/11/2012 06:39 PM, Gergely Nagy wrote: Long story short, I still don't see what the fuss is about. The fuss is about we're being told that there will be silent overwriting of configuration files without being prompted about changes, which potentially, will make it horrible to manage upgrades in a decent way without knowing the corner cases. On top of that, we're being told that this is the reason why we should use this system, which is totally the inverse of what we've been doing in Debian for years. Thomas -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4facf4fd.8000...@debian.org
Re: RFC: OpenRC as Init System for Debian
Steve McIntyre st...@einval.com writes: Jean-Christophe Dubacq wrote: If dpkg kept a copy of the original configuration file (to be retrieved at all times), it would be easier to spot local changes. I use etckeeper to do that, but it's a bit tiresome to isolate all local changes (I have to save the diffs somewhere) (and a lost hope if you do install etckeeper late in the workstation life). My git-fu is probably not good enough (I am probably looking for a pristine branch and a rebased local branch used in production). You might be interested in a proposal at UDS this week: https://blueprints.launchpad.net/ubuntu/+spec/foundations-q-dpkg-pristine-conffiles So basically, we'd have a directory of files under /etc that are not conffiles, and even made 0440. Amusing proposal. Why not move them outside of /etc then, if they are not configuration files, and should not be touched by the user? (Yeah, sure, they can be moved out of /etc, but that doesn't stop the original proposal being amusing, sorry.) -- |8] -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87fwb7t1vo.fsf@algernon.balabit
Re: RFC: OpenRC as Init System for Debian
Thomas Goirand z...@debian.org writes: On 05/11/2012 04:52 PM, Gergely Nagy wrote: Neither the FHS, nor the policy says anything about etc-overrides-lib as far as I can see. Neither pro or con. Do feel free to point me to the relevant section, would I be mistaken. Section 10.7.2 of dpm: Any configuration files created or used by your package must reside in |/etc|. The policy never talks about etc-overrides-lib configuration files, it only tells that all configuration files should go in /etc, and there's no exception, and it is also a must. But these are default settings, not configuration files. The configuration files *are* in /etc. Configuration files are stuff you want to change, defaults are things upstream (or at worst, the package maintainer) decides them to be, and the user has no business touching them. That is what configuration is for, to change the defaults. That the defaults happen to be files instead of some compiled in thing, is an implementation detail. But be my guest, if you take this seriously, please file a bug against X11 (see xorg.conf.d(5) for a reason) and other packages that do the same thing systemd does. -- |8] -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87bolvt1f6.fsf@algernon.balabit
Re: RFC: OpenRC as Init System for Debian
Thomas Goirand z...@debian.org writes: On 05/11/2012 06:39 PM, Gergely Nagy wrote: In other words, it does *exactly* the same thing systemd is criticised for. Which doesn't mean that it's a good practice. Tell me what you would gain, if there were no files under /lib/systemd, and all of these were compiled into the binary, please. Because that's the other option, as you *do not* let users change the defaults. You let them override them, you let them configure the system. (And that *is* being done in /etc.) There are *very* few programs that come without any kind of default, and even less, that let you change the default too. apt does not let you change the defaults, nor does dpkg. Both allow you to change their settings, but without recompiling, you can't change the defaults. Same happens with systemd, the difference is that it's easier to see the defaults, as they're broken out into files that are easy to copy and change as needed. -- |8] -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/874nrnt155.fsf@algernon.balabit
Re: RFC: OpenRC as Init System for Debian
Philip Hands wrote: The traditional Debian approach to /etc is largely self documenting, to the extent that one can generally walk into a site cold and (having established that they have decent backups) cheerfully do an upgrade on their Debian servers without anything breaking (I do this regularly). If you walk into a site cold, how do you tell if they have weird local configuration for something? It's much easier to check if there's something under /etc than to start checking whether the files match what's expected for the package version, if the the default files are always there even if nothing has been configured. The sources of potential breakage are highlighted by the packaging system, at which point you can read up on any package that needs attention with which you're not already familiar, while ignoring the ones that upgrade cleanly. And why would this have to be any worse with etc-overrides-lib? Why would this cause problems for Debian, except at most needing some changes to tools to better support this case? Or do you think implementing that would be hard? Are you volunteering to do that? If not then stop making assertions that simply require someone else to do a load of work to pander to your unusual tastes. If you are volunteering, then that's somewhat better (although I would prefer that we simply fix the packages to behave themselves in a proper Debian way instead). No, I'm not volunteering, mainly because I don't want to program in shell (which ucf seems to be implemented in). I can still estimate what such an implementation would need to do. You can't argue that everything which has not already been implemented would be a huge fundamental problem. If you want to argue that etc-overrides-lib would be fundamentally bad, hard to support, or undesirable to even try to support in Debian, then you should say more about implementation difficulties than just it's not implemented at the moment. George Danchev gave a proposed implementation of change alerts in an earlier mail: http://lists.debian.org/201205110212.30503.danc...@spnet.net While there are things you'd want to improve in a real implementation for packager convenience and better user interface (and the ucf part looks like it'd incorrectly create the file under /etc by default), I think that's enough to demonstrate this is not a particularly hard problem. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1336737949.2227.181.camel@glyph.nonexistent.invalid
Re: RFC: OpenRC as Init System for Debian
On Fri, May 11, 2012 at 04:39:22PM +0800, Thomas Goirand wrote: [snip] From: http://en.wikipedia.org/wiki/Configuration_file In computing, configuration files, or config files configure the initial settings for some computer programs. They are used for user applications, server processes and operating system settings. The fact that these files are in /lib and shouldn't be touched by the admin doesn't make them less configuration files. They still match the above definition from Wikipedia. Since when did Wikipedia have any relevance on Debian? If the old file in /lib isn't equal to the new file being installed to /lib, and there's a user supplied file in /etc rather than just the default (which would only include the version in lib), then prompt the user. If the user is running a non-interactive upgrade, fire off an e-mail or something. For any major changes to the /lib files (stuff that are likely to trigger user actions), NEWS.Debian should of course, as usual, contain a heads up. No need to explain again, again and again the same thing. We did understand what your point is, but still, we don't agree with you and Uoti. Move on. Talking about yourself in pluralis majestatis now? Just because something isn't supported currently in our tools doesn't make it impossible to support it. The very reason why our tools don't support it, is because *we don't want it. It's designed like this on purpose, and we are happy with the way things are right now. Yes, I get it that you are. Or are you somehow assuming that you can speak for all of Debian? I guess you're aware of the fact that I'm a DD too? Why can't you implement something like amavis, grub2, or apache are doing? Especially Amavis, where the default config is a conffile, but you can override what you need by using a higher number in the file name. It works well, it is integrated with Debian and the way things work... A solution with configuration files in /etc including, or overriding, defaults elsewhere works well too. gconf is a good example. Tollef's example of how to handle the case of a setting that can be set multiple times is probably needs some thought though, but that particular case can be solved by copying rather than including, if needs be. Anyway, I'm neither systemd maintainer nor upstream, so I don't believe I'm the right person to speak to. Then again, neither are you TTBOMK :) And debian-policy isn't set in stone. Otherwise it wouldn't have last been revised in February 2012 :) The debian-policy maybe, but the FHS, and config files in /etc *is* a very strong policy that you will not change in Debian, and for very valid reasons already described in this thread. Sigh. The config files remain in /etc. The defaults are not. There's nothing in FHS that contradicts such a behaviour. Regards: David -- /) David Weinehall t...@debian.org /) Rime on my window (\ // ~ // Diamond-white roses of fire // \) http://www.acc.umu.se/~tao/(/ Beautiful hoar-frost (/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120511122856.gg10...@suiko.acc.umu.se
Re: RFC: OpenRC as Init System for Debian
On May 11, Gergely Nagy alger...@balabit.hu wrote: Long story short, I still don't see what the fuss is about. Apparently the reason is that you do not understand the problem, since you keep getting back to the not relevant issue of software which supports placing configuration directives in multiple directories. This is not what etc-overrides-lib is about: with udev and systemd, if you create a file in /etc then the file with the same name in /lib is ignored. -- ciao, Marco signature.asc Description: Digital signature
Re: RFC: OpenRC as Init System for Debian
On May 11, Thomas Goirand z...@debian.org wrote: Long story short, I still don't see what the fuss is about. The fuss is about we're being told that there will be silent overwriting of configuration files without being prompted about changes, which potentially, will make it horrible to manage upgrades in a decent way without knowing the corner cases. No, not even that: if you edit files in /lib without being aware of the consequences then you are an idiot and deserve to suffer for it. The problem with etc-overrides-lib is that a file must be copied in full from /lib to /etc to be modified, and then future changes to the same file in /lib will be ignored (so maybe the package will break because these changes are required, etc). -- ciao, Marco signature.asc Description: Digital signature
Re: RFC: OpenRC as Init System for Debian
]] Thomas Goirand On 05/11/2012 06:39 PM, Gergely Nagy wrote: Long story short, I still don't see what the fuss is about. The fuss is about we're being told that there will be silent overwriting of configuration files without being prompted about changes, which potentially, will make it horrible to manage upgrades in a decent way without knowing the corner cases. I've not yet seen anybody saying that, so could you provide a reference, please? Preferably by somebody who is actually going to be doing some of the work. -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87fwb6oq1x@qurzaw.varnish-software.com
Re: RFC: OpenRC as Init System for Debian
Am 11.05.2012 14:30, schrieb Marco d'Itri: The problem with etc-overrides-lib is that a file must be copied in full from /lib to /etc to be modified, and then future changes to the same file in /lib will be ignored (so maybe the package will break because these changes are required, etc). You can either copy the file or use the .include directive (which was already mentioned) and only override the settings you need. So systemd provides both semantics and you can chose which one you want/need. Michael signature.asc Description: OpenPGP digital signature
Re: RFC: OpenRC as Init System for Debian
Thomas Goirand z...@debian.org writes: On 05/11/2012 06:39 PM, Gergely Nagy wrote: Long story short, I still don't see what the fuss is about. The fuss is about we're being told that there will be silent overwriting of configuration files without being prompted about changes, which potentially, will make it horrible to manage upgrades in a decent way without knowing the corner cases. There will be no overwriting of configuration files. There might be changes to defaults, like in every piece of software that is out there. When defaults change, unless care is being taken, things will break, indeed. That is not specific to systemd, and has nothing to do with its defaults being under /lib/systemd. Let me tell you three scenarios, just to demonstrate what I'm getting at: We have three programs: * We have a program, that has a few defaults compiled in, and reads its configuration from /etc/program.conf. Lets call this the 'def-etc' program. * We have another, that has no built in defaults, ships a config file in /etc/program/defaults.conf, and includes snippets from /etc/program/conf.d/. We'll call this 'def-conf.d'. * We have a third program that comes with no compiled-in defaults, but has them in /lib/program instead. It reads configuration from snippets under /etc/program/. We'll call this 'def-lib'. In the first case, since there is a single config file, lets assume we modified that. In the other two cases, we placed snippets in the appropriate directory, and did not touch the config file that contains the default config. When the first program changes its default, since it is compiled in, you get no notofication, no prompt, no nothing - it wasn't in a config file, it was compiled in. When the second program changes its default, since you did not modify the default config, that will be overwritten, and the only notice you get is a Configuration file updated scrolling by, no prompt whatsoever, no visible news, just something you've grown to expect, and trust your tool to handle right. When the third program changes its default, since you can't modifiy the default config, you get no notification, no prompt, no nothing. In all three cases, you get no prompt at all, because no tool in Debian can handle the change of default settings. We're not prepared for that, nor can we ever be. We can handle configuration change, but defaults are *not* configuration. Configuration is things you're allowed to change. On top of that, we're being told that this is the reason why we should use this system, which is totally the inverse of what we've been doing in Debian for years. I can't speak for anyone else who thinks etc-overrides-non-etc isn't the work of the $devil, I merely think that this is a valid way to treat default (unchangeable by the user) settings. It will not work for everyone, nor should it. But for specific cases, it is useful, and makes sense. That is all. -- |8] -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87zk9esxu3.fsf@algernon.balabit
Re: RFC: OpenRC as Init System for Debian
Am 11.05.2012 14:30, schrieb Marco d'Itri: The problem with etc-overrides-lib is that a file must be copied in full from /lib to /etc to be modified, and then future changes to the same file in /lib will be ignored (so maybe the package will break because these changes are required, etc). This argument goes both ways, though. I've received more than one bug report about uses fiddling with their sysv init scripts, then blindly pressing ok during the upgrade or using non-interactive mode (which kept the locally modified version) and the daemon failed to start due to required changes being missing in the locally modified version. Also, the recent discussions somehow make it look like you constantly need to change the systemd .service files. This should only be necessary in the rarest of cases. Those systemd .service are in the vast majority of cases really simple (most just containing the path to the executable and the type) and comparable in complexity with dbus (system-)service files which have been installed in /usr/share/dbus/ forever. Michael signature.asc Description: OpenPGP digital signature
Re: RFC: OpenRC as Init System for Debian
]] Gergely Nagy Tollef Fog Heen tfh...@err.no writes: ]] Gergely Nagy In that case, the including file can be changed (by the admin) to be a separate file, that does not include, and get the usual conffile conflict dpkg prompt. How would that work? I have /lib/systemd/system/foo.service and want to change something in it, I then create /etc/systemd/system/foo.service with a copy of the /lib one plus whatever changes I want. The version in /lib is then updated. How is the admin notified? NEWS.Debian, like with any significant default change. So you won't get the dpkg conffile conflict prompt, then? Can you explain what the scenario you talked about would look like, since it's apparently not the scenario I was thinking about? Other than that, the best I can think of is keeping track of what version of the package a default changed in, and triggering something from preinst, when upgrading from a version that is older than the change. This is basically what the tool I'm suggesting to write will do. This however, requires a lot of manual work, might aswell shovel the whole thing from under /lib to /etc then, but then we still didn't solve the problem: suppose there is a unit file that supports starting multiple instances, by way of symlinking. I start to use this feature, I change nothing, just symlink files around. At some point, this feature gets removed, my upgrade succeeds, but my instances won't start anymore, and the best notification I have is something that scrolled by that a conffile was upgraded. You'll get a notification, since the file will have changed, then. -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87boluopkt@qurzaw.varnish-software.com
Re: RFC: OpenRC as Init System for Debian
On May 11, Michael Biebl bi...@debian.org wrote: You can either copy the file or use the .include directive (which was already mentioned) and only override the settings you need. Not with udev or kmod. The problem with etc-overrides-lib is that a file must be copied in full from /lib to /etc to be modified, and then future changes to the same file in /lib will be ignored (so maybe the package will break because these changes are required, etc). This argument goes both ways, though. I've received more than one bug report about uses fiddling with their sysv init scripts, then blindly pressing ok during the upgrade or using non-interactive mode (which kept the locally modified version) and the daemon failed to start due to required changes being missing in the locally modified version. But this is a user error. The point is that with etc-overrides-lib there is no prompt at all when the upstream configuration changes. This is good for Red Hat, because they can guarantee that no relevant changes will appear until the next major release, but is bad for us who actually support system upgrades. -- ciao, Marco signature.asc Description: Digital signature
Re: RFC: OpenRC as Init System for Debian
On 05/11/2012 08:30 PM, Marco d'Itri wrote: On May 11, Thomas Goirand z...@debian.org wrote: Long story short, I still don't see what the fuss is about. The fuss is about we're being told that there will be silent overwriting of configuration files without being prompted about changes, which potentially, will make it horrible to manage upgrades in a decent way without knowing the corner cases. No, not even that: if you edit files in /lib without being aware of the consequences then you are an idiot and deserve to suffer for it. The problem with etc-overrides-lib is that a file must be copied in full from /lib to /etc to be modified, and then future changes to the same file in /lib will be ignored (so maybe the package will break because these changes are required, etc). Yes, that's exactly what I don't like, and what I want to avoid!!! I want to be prompted, shown a diff, so I can see what's going on, and then take my own decision based on this diff. So, in fewer words: the current normal behavior in Debian. Thomas -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4fad0f7a.2020...@debian.org
Re: RFC: OpenRC as Init System for Debian
On 05/11/2012 08:33 PM, Michael Biebl wrote: Am 11.05.2012 14:30, schrieb Marco d'Itri: The problem with etc-overrides-lib is that a file must be copied in full from /lib to /etc to be modified, and then future changes to the same file in /lib will be ignored (so maybe the package will break because these changes are required, etc). You can either copy the file or use the .include directive (which was already mentioned) and only override the settings you need. So systemd provides both semantics and you can chose which one you want/need. Michael But upon upgrades, it's still a silent thing. The configuration file in /lib is overwritten and users wont know about the changes. Thomas -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4fad0fc2.4010...@debian.org
Re: RFC: OpenRC as Init System for Debian
On 05/11/2012 08:28 PM, David Weinehall wrote: Talking about yourself in pluralis majestatis now? Yes, I get it that you are. Or are you somehow assuming that you can speak for all of Debian? I guess you're aware of the fact that I'm a DD too? By reading other replies, I thought there was only yourself and Uoti. Now I can see that Gergely is also on your side, and then I don't think there's a large consensus anymore. Thomas -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4fad11f1.40...@debian.org
Re: RFC: OpenRC as Init System for Debian
On 05/11/2012 07:04 PM, Gergely Nagy wrote: Steve McIntyre st...@einval.com writes: Jean-Christophe Dubacq wrote: If dpkg kept a copy of the original configuration file (to be retrieved at all times), it would be easier to spot local changes. I use etckeeper to do that, but it's a bit tiresome to isolate all local changes (I have to save the diffs somewhere) (and a lost hope if you do install etckeeper late in the workstation life). My git-fu is probably not good enough (I am probably looking for a pristine branch and a rebased local branch used in production). You might be interested in a proposal at UDS this week: https://blueprints.launchpad.net/ubuntu/+spec/foundations-q-dpkg-pristine-conffiles So basically, we'd have a directory of files under /etc that are not conffiles, and even made 0440. Amusing proposal. Why not move them outside of /etc then, if they are not configuration files, and should not be touched by the user? (Yeah, sure, they can be moved out of /etc, but that doesn't stop the original proposal being amusing, sorry.) The setting of unix rights 0440 is indeed very amusing. The only nice point about this proposal is that it's going to make happy hard drive factories: they will be able to sell bigger hard drive for no valid good reasons. Seriously, can't someone who broke his configuration wget the package, and use mc to get into the .deb and get the original configuration file??? Overall, all this proposal assumes that users are idiots who love to change things they don't understand, and aren't smart enough to restore. I can't believe that newbies favorite game would be changing randomly the content of /etc/init. And at the same time, I can't believe that experts tweaking upstart jobs wouldn't know how to restore them. Thomas -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4fad144c.1050...@debian.org
Re: RFC: OpenRC as Init System for Debian
m...@linux.it (Marco d'Itri) writes: On May 11, Nikolaus Rath nikol...@rath.org wrote: Wrong: since you have to copy the whole file to override it, and files in /lib have no conffiles handling, after an upgrade you will not know what was changed by you and what was changed upstream. I think everyone here agrees with that. The interesting case is when files in /etc/ can either explicitly include the /lib file, or implicitly override the /lib settings. I do not know about any package which work this way, Well, systemd has been mentioned one or two times here in the last weeks. but there is any then the problem is not different from packages which support multiple configuration file fragments in /etc, ship the default configuration in /etc and allow it to be modified by other configuration fragments in /etc (e.g. Apache). I agree, and therefore I'm surprised that some people are getting so aggravated about this if the default configuration is installed in /lib rather than /etc. Best, -Nikolaus -- »Time flies like an arrow, fruit flies like a Banana.« PGP fingerprint: 5B93 61F8 4EA2 E279 ABF6 02CF A9AD B7F8 AE4E 425C -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/8762c27shc@inspiron.ap.columbia.edu
Re: RFC: OpenRC as Init System for Debian
* Thomas Goirand z...@debian.org [120511 04:45]: On 05/11/2012 04:04 AM, David Weinehall wrote: From: http://en.wikipedia.org/wiki/Configuration_file In computing, configuration files, or config files configure the initial settings for some computer programs. They are used for user applications, server processes and operating system settings. The fact that these files are in /lib and shouldn't be touched by the admin doesn't make them less configuration files. They still match the above definition from Wikipedia. And debian-policy isn't set in stone. Otherwise it wouldn't have last been revised in February 2012 :) The debian-policy maybe, but the FHS, and config files in /etc *is* a very strong policy that you will not change in Debian, and for very valid reasons already described in this thread. The FHS is very specific that /etc is for *Host-specific* system configuration, not upstream defaults or distribution-specific configuration. The clear intent is that this is where files that are intended to be modified by the local system administrator are placed. Files containing distribution-specific defaults, whether they match some definition of configuration file or not, do not belong here unless the they are also intended to be edited by the local sysadmin. Using a Wikipedia definition must be done with careful consideration, as they are often either over generalized or too specific. In this case I believe the Wikipedia definition is not in the least relevant to the subtleties being disputed here. Debian policy does not explicitly differentiate between host-specific configuration and Debian-provided default configuration, but it does say, Typically, configuration files are intended to be modified by the system administrator (if needed or desired) to conform to local policy or to provide more useful site-specific behavior. Following the FHS is, however, a must in Debian policy except where policy explicitly provides an exception or conflicts with the FHS. It is clear to me that etc-overrides-non-etc is perfectly compliant with Debian policy as long as the sysadmin does not need to modify the non-etc files to obtain the desired behavior. I have been using Debian since 1998, and IME the cases where changes to the Debian-supplied configuration files would have caused breakage if the Debian defaults had been in /usr/lib/package and only local modifications were in /etc have been rare. On the other hand, the cases where this model would have both obviated the need for a manual merge and resulted in exactly the configuration I intended are extremely common. Gergely Nagy has shown elsewhere in this thread that no matter which configuration model you use, there are cases where you might not get a notification of incompatible default configuration from dpkg on upgrade. On the other hand, the etc-overrides-non-etc model significantly simplifies most of the common default-configuration-change cases. For clarity, the etc-overrides-non-etc model that I am talking about is where the file in /etc can override individual values, not where the file in /etc must replace the entirety of the non-etc configuration. While I agree that etc-overrides-non-etc may not be the best model for all software, it is the best for some and at least as good for many other packages. ...Marvin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120511150832.ga7...@cleo.wdw
Re: RFC: OpenRC as Init System for Debian
Thomas Goirand z...@debian.org writes: Section 10.7.2 of dpm: Any configuration files created or used by your package must reside in |/etc|. Configuration file is a term of art that is previously defined in the Policy document. It doesn't mean what you're taking it to mean. There isn't anything about etc-overrides-lib that violates the letter of Policy. (The expectations of a Debian administrator are another question.) -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/8739767l76@windlord.stanford.edu
Re: RFC: OpenRC as Init System for Debian
On 11/05/2012 15:29, Thomas Goirand wrote: The setting of unix rights 0440 is indeed very amusing. Yes. Maybe the mean to chmod a-w everything, for some applications will not work with so large modes (sudo, for example). The only nice point about this proposal is that it's going to make happy hard drive factories: they will be able to sell bigger hard drive for no valid good reasons. Come on! Less than 20M, it could trivially be compressed. Seriously, can't someone who broke his configuration wget the package, and use mc to get into the .deb and get the original configuration file??? Not necessarily. 1) Many configuration files are dynamically generated through debconf questions, which root may not be able to rerun to obtain the same result. 2) What if you borked your network configuration? What if the malfunction is due to a complex interaction between several packages (let's say, a FORCESSL option on some service A, and a libssl upgrade breaks A but only if the FORCESSL option is used?) Being able 3) I think etckeeper could do the job without much development. However, it will make the hard drive factories happy (according to you). Overall, all this proposal assumes that users are idiots who love to change things they don't understand, and aren't smart enough to restore. I can't believe that newbies favorite game would be changing randomly the content of /etc/init. And at the same time, I can't believe that experts tweaking upstart jobs wouldn't know how to restore them. I find your attitude assumes users always have the knowledge and the time to investigate everything. This is not the reality. Sincerly, -- Jean-Christophe Dubacq signature.asc Description: OpenPGP digital signature
Re: RFC: OpenRC as Init System for Debian
On 05/11/2012 11:08 PM, Marvin Renich wrote: For clarity, the etc-overrides-non-etc model that I am talking about is where the file in /etc can override individual values, not where the file in /etc must replace the entirety of the non-etc configuration. This case is much much more acceptable to me. I wouldn't see any problem with it. I just don't want that new configuration values to be silently ignored upon upgrades, that's all I'm saying. Thomas -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4fad3cb8.1080...@debian.org
Re: RFC: OpenRC as Init System for Debian
On 05/12/2012 12:22 AM, Jean-Christophe Dubacq wrote: I find your attitude assumes users always have the knowledge and the time to investigate everything. This is not the reality. Sincerly, Not at all. Anyone without the knowledge will not be able to restore anything anyway. Anyone with the knowledge will know how to get the original file. Yes, it will take more time to do that, but do you think this is the kind of operation you need to do every day? I'd say, once every 5 years maybe? Very rarely, I do a purge then reinstall, but never it happened to me that my system was in such state that I had to recover by hand a configuration file, using the single user boot. Did this happen to you at some point? Anyone else? I'm not bashing the idea so much, as it is a harmless one, I just think it is simply a useless feature, and I don't think it's worth investing any human time on this. Thomas -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4fad4670.5030...@debian.org
Re: RFC: OpenRC as Init System for Debian
On 11/05/2012 19:03, Thomas Goirand wrote: On 05/12/2012 12:22 AM, Jean-Christophe Dubacq wrote: I find your attitude assumes users always have the knowledge and the time to investigate everything. This is not the reality. Sincerly, Not at all. Anyone without the knowledge will not be able to restore anything anyway. Anyone with the knowledge will know how to get the original file. Yes, it will take more time to do that, but do you think this is the kind of operation you need to do every day? I'd say, once every 5 years maybe? Very rarely, I do a purge then reinstall, but never it happened to me that my system was in such state that I had to recover by hand a configuration file, using the single user boot. Did this happen to you at some point? Anyone else? Yes, several times indeed. Most times when upgrading network packages at the same time. I'm not bashing the idea so much, as it is a harmless one, I just think it is simply a useless feature, and I don't think it's worth investing any human time on this. I think it would be really great to have some program being able to output all manual differences to all /etc files really useful for maintenance. I used to do that, but some rapidly evolving configuration files make it quickly unmaintainable (php.ini comes to mind: I always have to put back the upload_max_filesize to a superior value, and this one-line difference makes something that should be really, really simple (upgrading php, even using stable+security) a pain because one gets manually prompted about the differences, even if they are trivial to merge. -- Jean-Christophe Dubacq signature.asc Description: OpenPGP digital signature
Re: RFC: OpenRC as Init System for Debian
Thomas Goirand z...@debian.org writes: Seriously, can't someone who broke his configuration wget the package, and use mc to get into the .deb and get the original configuration file??? FWIW, I'd love an easier way to keep track of my /etc, where upstream changes and my own are on a separate branch. So the idea is not entirely silly, and would be useful even for folk like myself, who - at least I dare hope so - are not entirely clueless. The solution, however, is very simple: wrap dpkg calls, and have a list of files to watch for. Whenever a package touches a file that's on the list, fire a trigger, that can run a hook. Said hook can be something provided by etckeeper or similar, that would extract the appropriate file from the deb, and commit it to the upstream branch of /etc, for example. Then proceed on, and do whatever else needs to be done. And boom! We have a way to allow experienced users to keep track of their /etc properly, that does not fall on its face when I notice a bad config change in the upstream config two updates later. Oh, and this whole thing need not live in /etc at all, and can follow anything, not just config files. It's perfectly able to notice changes in /lib/systemd too, or pretty much anywhere else. I actually just implemented that (it took 10 minutes, becuase I screwed up first), and will be testing how it works over the next few weeks. -- |8] -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87y5oyr0eq@luthien.mhp
Re: RFC: OpenRC as Init System for Debian
m...@linux.it (Marco d'Itri) writes: On May 11, Thomas Goirand z...@debian.org wrote: Long story short, I still don't see what the fuss is about. The fuss is about we're being told that there will be silent overwriting of configuration files without being prompted about changes, which potentially, will make it horrible to manage upgrades in a decent way without knowing the corner cases. No, not even that: if you edit files in /lib without being aware of the consequences then you are an idiot and deserve to suffer for it. The problem with etc-overrides-lib is that a file must be copied in full from /lib to /etc to be modified, and then future changes to the same file in /lib will be ignored (so maybe the package will break because these changes are required, etc). And...? If it were somewhere under /usr/share/doc/$package/examples, how would that be different? (Assuming that the *default* would then be wired into the binary) You'd still need to copy the file, and if the defaults change under you, you're screwed. Even worse if you have to dig out the possible options, and their defaults from (possibly stale) documentation. But even if everything is in /etc, you can still easily screw yourself over: conf.d/ can very easily break the exact same way. It's not etc-overrides-lib that is the problem. It's defaults changing without notice that is. With the defaults being broken out into files, making a tool that notifies the user preemptively when a default will change, and stops the upgrade, is possible, and is not even hard. You can't do that when the defaults are either unavailable, or subject to change by the admin. -- |8] -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87r4uqqzwt@luthien.mhp
Re: RFC: OpenRC as Init System for Debian
Thomas Goirand z...@debian.org writes: On 05/11/2012 08:33 PM, Michael Biebl wrote: Am 11.05.2012 14:30, schrieb Marco d'Itri: The problem with etc-overrides-lib is that a file must be copied in full from /lib to /etc to be modified, and then future changes to the same file in /lib will be ignored (so maybe the package will break because these changes are required, etc). You can either copy the file or use the .include directive (which was already mentioned) and only override the settings you need. So systemd provides both semantics and you can chose which one you want/need. Michael But upon upgrades, it's still a silent thing. The configuration file in /lib is overwritten and users wont know about the changes. Likewise for *every* other case where the default changes. There's nothing different. Nothing. Nada. Except you can write a tool to warn in *this* case, because the defaults are available in a diffable format. -- |8] -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87mx5eqztf@luthien.mhp
Re: RFC: OpenRC as Init System for Debian
OoO Peu avant le début de l'après-midi du vendredi 11 mai 2012, vers 13:20, Gergely Nagy alger...@balabit.hu disait : In other words, it does *exactly* the same thing systemd is criticised for. Which doesn't mean that it's a good practice. Tell me what you would gain, if there were no files under /lib/systemd, and all of these were compiled into the binary, please. Because that's the other option, as you *do not* let users change the defaults. You let them override them, you let them configure the system. (And that *is* being done in /etc.) There are *very* few programs that come without any kind of default, and even less, that let you change the default too. apt does not let you change the defaults, nor does dpkg. Both allow you to change their settings, but without recompiling, you can't change the defaults. Same happens with systemd, the difference is that it's easier to see the defaults, as they're broken out into files that are easy to copy and change as needed. Yes, that's very true. We are just used that the kind of defaults in init to be in /etc. But nothing is set in stone. I was first against this etc-override-lib behaviour but your arguments are sound and I am now convinced that we should keep the way systemd is doing things. Moreover, in the case of systemd, there are other mechanisms that can be used to customize a configuration file for the more common modifications (handling dependencies and ordering) using symbolic links. This way, there is no need to copy the file from /lib in /etc to do the modifications. Still in the case of systemd, a README put in /etc/systemd may be used to explain the whole etc-override-lib to users that are not expecting such behaviour. A README is not a configuration file but there is one in /etc/init.d as well. -- Vincent Bernat ☯ http://vincent.bernat.im #if 0 2.2.16 /usr/src/linux/fs/buffer.c pgpOoyGiMli3V.pgp Description: PGP signature
Re: RFC: OpenRC as Init System for Debian
SEEWEB - Marco d'Itri m...@seeweb.it writes: But this is a user error. The point is that with etc-overrides-lib there is no prompt at all when the upstream configuration changes. Bzzt. There's no prompt ever when upstream defaults change. Unless *all* the defaults are laid out in /etc, *AND* the user modified that particular file. If suddenly /etc/$program.conf, which I never modified changes, and I have custom snippets under /etc/$program.d/*.conf, those snippets might very well break. Do I get a prompt? No. The closest I get is that $program.conf was upgraded. I see no diff, unless I keep track of my /etc in other ways. -- |8] -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87ipg2qzmc@luthien.mhp
Re: RFC: OpenRC as Init System for Debian
Thomas Goirand z...@debian.org writes: On 05/11/2012 11:08 PM, Marvin Renich wrote: For clarity, the etc-overrides-non-etc model that I am talking about is where the file in /etc can override individual values, not where the file in /etc must replace the entirety of the non-etc configuration. This case is much much more acceptable to me. I wouldn't see any problem with it. I just don't want that new configuration values to be silently ignored upon upgrades, that's all I'm saying. I agree, that seeing the defaults change would be lovely. With the defaults being in /lib, it's possible to write a tool that notifies you. With the defaults being in a monolithic blob, possibly inside a binary, it is not. -- |8] -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87ehqqqzeu@luthien.mhp
Re: RFC: OpenRC as Init System for Debian
Tollef Fog Heen tfh...@err.no writes: ]] Gergely Nagy Tollef Fog Heen tfh...@err.no writes: ]] Gergely Nagy In that case, the including file can be changed (by the admin) to be a separate file, that does not include, and get the usual conffile conflict dpkg prompt. How would that work? I have /lib/systemd/system/foo.service and want to change something in it, I then create /etc/systemd/system/foo.service with a copy of the /lib one plus whatever changes I want. The version in /lib is then updated. How is the admin notified? NEWS.Debian, like with any significant default change. So you won't get the dpkg conffile conflict prompt, then? Can you explain what the scenario you talked about would look like, since it's apparently not the scenario I was thinking about? I believe we're talking about the same scenario, and I was hasty to suggest that NEWS.Debian is the only way - see below. Other than that, the best I can think of is keeping track of what version of the package a default changed in, and triggering something from preinst, when upgrading from a version that is older than the change. This is basically what the tool I'm suggesting to write will do. During my trip back home, I wrote that tool. It's very crude and hackish at the moment, but with a little bit of support from, say, apt (or perhaps dpkg, but that's less likely), it could be made into something nice. Basically, I divert dpkg, and catch all -i calls, see what debs we're called on, list the files therein. If any of the files are on the watchlist, I launch the triggers, with apropriate parameters. The only trigger I have implemented so far will extract the files that triggered it, and put them in version control, onto the appropriate upstream branch. Then proceed on. I could enhance it to abort the installation, or send mail, or pause and do some ucf magic, to check whether overrides in /etc exist at all, and so on and so forth. I only needed the shovel-into-a-vcs-branch thing, so that's what I have. Adding the rest isn't hard, either. The advantage here, is that the packager need not keep track of what changed in which version, and admins can extend the watchlist, and change the triggered actions too, to make it better suit their own needs. This also means that in case of bugs, we don't need to fix maintainer scripts, just a single application. -- |8] -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87aa1eqz1g@luthien.mhp
Re: RFC: OpenRC as Init System for Debian
On Fri, May 11, 2012 at 11:08:32AM -0400, Marvin Renich wrote: The FHS is very specific that /etc is for *Host-specific* system configuration, not upstream defaults or distribution-specific configuration. The clear intent is that this is where files that are intended to be modified by the local system administrator are placed. No, this is a total retcon. When the FHS was written, this was definitely NOT a shared understanding of a difference between host-specific configuration and upstream defaults / distribution-specific configuration. Distribution defaults still would go in /etc whenever it was expected that an admin might want to edit the file. This has been the convention for more than a decade. Files containing distribution-specific defaults, whether they match some definition of configuration file or not, do not belong here unless the they are also intended to be edited by the local sysadmin. Yes. The issue is not that either system is a violation of the standard, because intent is relevant here. If the upstream *intends* the file to be a template that's overridden using a separate file, then /usr is the right place. If the upstream intends the user to edit the provided file to make their changes, it belongs in /etc. If the defaults are built into the binary, that's perfectly fine too. What *is* an issue is when upstreams decide to ship their defaults in /usr, but require users to duplicate information between /usr templates and /etc config files and ignore the contents of /usr in favor of the contents of /etc. This is also not a violation of FHS, but it IS a crappy design. When software is not able to override configuration *settings* with fine granularity via /etc, the entire thing should go under /etc. Doing otherwise makes this horrible for upgrades. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Re: RFC: OpenRC as Init System for Debian
Steve Langasek vor...@debian.org writes: What *is* an issue is when upstreams decide to ship their defaults in /usr, but require users to duplicate information between /usr templates and /etc config files and ignore the contents of /usr in favor of the contents of /etc. This is also not a violation of FHS, but it IS a crappy design. When software is not able to override configuration *settings* with fine granularity via /etc, the entire thing should go under /etc. Doing otherwise makes this horrible for upgrades. Yes, this, with the caveat that coming up with a new tool that would do the right thing, as Tollef discussed, would be a reasonable substitute for putting everything in /etc. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87sjf6ih8l@windlord.stanford.edu
Re: RFC: OpenRC as Init System for Debian
* Steve Langasek vor...@debian.org [120511 16:17]: On Fri, May 11, 2012 at 11:08:32AM -0400, Marvin Renich wrote: The FHS is very specific that /etc is for *Host-specific* system No, this is a total retcon. When the FHS was written, this was definitely NOT a shared understanding of a difference between host-specific configuration and upstream defaults / distribution-specific configuration. I obviously read more into host-specific than was intended. Distribution defaults still would go in /etc whenever it was expected that an admin might want to edit the file. This has been the convention for more than a decade. Agree completely. See the next sentence. Files containing distribution-specific defaults, whether they match some definition of configuration file or not, do not belong here unless the they are also intended to be edited by the local sysadmin. Yes. The issue is not that either system is a violation of the standard, because intent is relevant here. If the upstream *intends* the file to be a template that's overridden using a separate file, then /usr is the right place. If the upstream intends the user to edit the provided file to make their changes, it belongs in /etc. If the defaults are built into the binary, that's perfectly fine too. I agree completely. I was responding specifically to the assertion that the definition of configuration file from Wikipedia meant that Debian must put files containing distribution-specific defaults in /etc, regardless of whether or not they were intended to be modified by the local sysadmin. What *is* an issue is when upstreams decide to ship their defaults in /usr, but require users to duplicate information between /usr templates and /etc config files and ignore the contents of /usr in favor of the contents of /etc. This is also not a violation of FHS, but it IS a crappy design. Again, I agree completely. See the part of my message that you did not include where I clarified to which etc-overrides-non-etc model I was referring. When software is not able to override configuration *settings* with fine granularity via /etc, the entire thing should go under /etc. Doing otherwise makes this horrible for upgrades. Absolutely. Again, see my clarification of how I was using etc-overrides-non-etc. I did not go into what I think is wrong with default in /usr, copy entirety to /etc and edit in order to override a single setting because I was specifically trying to address the other poster's assertion that placing anything that matches the Wikipedia definition of configuration file anywhere other than /etc was a violation of a must in Debian policy. ...Marvin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120511210825.gc7...@cleo.wdw
Re: RFC: OpenRC as Init System for Debian
On Wed, May 09, 2012 at 12:46:40PM -0700, Josh Triplett wrote: It also means that I don't get a pile of noise in etckeeper from all the upgrades of default configurations, so that my commits to etckeeper primarily consist of my own local changes. I don't personally use etckeeper but it strikes me that one advantage of storing your /etc in a VCS would surely be being able to distinguish local and system changes, perhaps storing each in a separate branch (with the merged result matching the live /etc). If etckeeper doesn't do this now, perhaps it could do in future. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120510093304.GK8272@debian
Re: RFC: OpenRC as Init System for Debian
Uoti Urpala uoti.urp...@pp1.inet.fi writes: Machine-specific configuration belongs in /etc. The default behavior of the tools doesn't. Agree. Copying a large set of default policies into /etc just because they *can* be overridden is not user friendly. And it does not make the defaults any more configuration either. It just hides important local changes and makes it difficult both for the user and the application itself to distinguish between defaults and configuration overrides. A default setting does not count as configuration until it is changed, IMHO. Bjørn -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87397844h3@nemi.mork.no
Re: RFC: OpenRC as Init System for Debian
Steve McIntyre wrote: No, really - please *do* do this. The fact that a lot of the software coming out of RedHat development seems to be designed solely for their use, including working around the missing/broken features of RPM, I'm curious exactly what you mean by this, since my own experience has been that rpm is more flexible than dpkg. -kgd, longtime RedHat-er torn between a distro that I get along with and a distro with at least three kitchen sinks included -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4fabcd92.4060...@vianet.ca
Re: RFC: OpenRC as Init System for Debian
On Thursday 10 May 2012 00:22:11 Uoti Urpala wrote: Steve McIntyre wrote: Josh Triplett wrote: Marco d'Itri wrote: The more I think about it, the more I suspect that the correct solution would be to just symlink /lib/udev/rules.d/ to /etc/udev/rules.d/ and so on. Please don't. As a user, I find it highly preferable for packages to install their default configuration in /lib and just have overrides in /etc, and I'd love to see that trend continue. That setup lets me trivially construct personal configuration packages that ship the overriding files in /etc, without having to play ugly games with dpkg-divert of conffiles. It also means that I don't get a pile of noise in etckeeper from all the upgrades of default configurations, so that my commits to etckeeper primarily consist of my own local changes. No, really - please *do* do this. The fact that a lot of the software coming out of RedHat development seems to be designed solely for their use, including working around the missing/broken features of RPM, is seriously annoying. Configuration belongs in /etc, we know this. We have a well-designed and implemented set of tools in Debian based on that standard. Machine-specific configuration belongs in /etc. The default behavior of the tools doesn't. For some reason or another the vast majority of applications have not been following this approach. I'm not going to argue whether is makes sense or not. Josh Triplett provided multiple technical reasons why etc-overrides-lib is preferable. The ONLY technical reason you gave to prefer traditional conffiles was that there already is a set of tools for that in Debian. Your comparison is misguided. The vast majority of applications do not follow etc-overrides-lib (some will never follow) so their configuration files should be properly managed as well, and dpkg's conffiles facility, dpkg's maintainer scripts in conjunction with things like ucf and debconf are quite powerful mechanisms to employ which have been proven for the last decade. Contrast this to the rpm systems trashing locally modified configuration files in /etc/ for the last decade. It is also trivial for the debian packages to contain default configuration files so users and tools could refer to them on demand, and this has nothing to do with the packaging system itself. OTOH, applications following etc-overrides-lib happily run on Debian systems in the way they run on others. It is not like the semantics of separating the default and locally modified configuration files in two directories is some sort of giant invention, never heard of before. It is also trivial to guess that their configuration files could also be managed by calling tools from dpkg's maintainer scripts in order to communicate with the user or provide assistance Who's the one choosing his preferred configuration format based on the limitations of his preferred packaging system here? Hint: it's not Red Hat. You're good, but I'd better watch Peter Sellers, honestly. -- pub 4096R/0E4BD0AB people.fccf.net/danchev/key pgp.mit.edu -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201205101802.37898.danc...@spnet.net
Re: RFC: OpenRC as Init System for Debian
George Danchev wrote: On Thursday 10 May 2012 00:22:11 Uoti Urpala wrote: Steve McIntyre wrote: No, really - please *do* do this. The fact that a lot of the software coming out of RedHat development seems to be designed solely for their use, including working around the missing/broken features of RPM, is seriously annoying. Configuration belongs in /etc, we know this. We have a well-designed and implemented set of tools in Debian based on that standard. Machine-specific configuration belongs in /etc. The default behavior of the tools doesn't. For some reason or another the vast majority of applications have not been following this approach. I'm not going to argue whether is makes sense or not. The reason why most old applications do not follow that approach (at least not yet) is pretty obvious: their authors never considered it. etc-overrides-lib semantics have only become a seriously considered alternative fairly recently. Josh Triplett provided multiple technical reasons why etc-overrides-lib is preferable. The ONLY technical reason you gave to prefer traditional conffiles was that there already is a set of tools for that in Debian. Your comparison is misguided. Which comparison are you talking about? From your following text it seems you mean the comparison between 1) criticizing Red Hat for (allegedly) letting packaging system limitations affect the choice of configuration format and 2) saying Debian should choose its preferred configuration format based on the limitations of its packaging system, though that comparison does not appear in the text you quoted. The vast majority of applications do not follow etc-overrides-lib (some will never follow) so their configuration files should be properly managed as well, and dpkg's conffiles facility, dpkg's maintainer scripts in conjunction with things like ucf and debconf are quite powerful mechanisms to employ which have been proven for the last decade. Contrast this to the rpm systems trashing locally modified configuration files in /etc/ for the last decade. It is also trivial for the debian packages to contain default configuration files so users and tools could refer to them on demand, and this has nothing to do with the packaging system itself. You're pretty much just saying that dpkg and helpers like ucf have implemented better functionality than rpm. I don't see how that's relevant to the discussion. I don't think it makes the above comparison any less valid. And generally, I don't think the packaging system issues would be so difficult that they should have a major influence on what configuration model to use. OTOH, applications following etc-overrides-lib happily run on Debian systems in the way they run on others. It is not like the semantics of separating the default and locally modified configuration files in two directories is some sort of giant invention, never heard of before. It is also trivial to guess that their configuration files could also be managed by calling tools from dpkg's maintainer scripts in order to communicate with the user or provide assistance Yes, nobody has brought up reasons why this wouldn't work. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1336668798.2227.58.camel@glyph.nonexistent.invalid
Re: RFC: OpenRC as Init System for Debian
On Wed, May 09, 2012 at 03:47:21PM +0200, Gergely Nagy wrote: Tollef Fog Heen tfh...@err.no writes: ]] Philipp Kern You will not, however, get a conffile update prompt when the system file changes (e.g. to update your own local copy to incorporate the fix). This is something I'm pondering if we should handle in either a systemd trigger or a tool that packages shipping systemd files can call to tell the user about any changes. (Basically a wrapper around ucf, probably.) Such a tool would certainly be very useful, but doing it right would be fairly hard, as far as I see. And it would require assistance from at least the package maintainer, to mark in which versions the unit file under /lib changed, so that it can trigger only when appropriate and not on every upgrade. (And there's possibly other corner cases to consider, but they escape me right now..) if [ file in etc -ot file in /lib ]; then warn user that updates might be needed fi Regards: David -- /) David Weinehall t...@debian.org /) Rime on my window (\ // ~ // Diamond-white roses of fire // \) http://www.acc.umu.se/~tao/(/ Beautiful hoar-frost (/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120510171250.ge10...@suiko.acc.umu.se
Re: RFC: OpenRC as Init System for Debian
On May 10, Bjørn Mork bj...@mork.no wrote: Agree. Copying a large set of default policies into /etc just because they *can* be overridden is not user friendly. And it does not make the defaults any more configuration either. It just hides important local changes and makes it difficult both for the user and the application itself to distinguish between defaults and configuration overrides. Wrong: since you have to copy the whole file to override it, and files in /lib have no conffiles handling, after an upgrade you will not know what was changed by you and what was changed upstream. Obviously this is not a problem for Red Hat since they do not support upgrades between major releases. -- ciao, Marco signature.asc Description: Digital signature
Re: RFC: OpenRC as Init System for Debian
On 10/05/2012 19:34, Marco d'Itri wrote: On May 10, Bjørn Mork bj...@mork.no wrote: Agree. Copying a large set of default policies into /etc just because they *can* be overridden is not user friendly. And it does not make the defaults any more configuration either. It just hides important local changes and makes it difficult both for the user and the application itself to distinguish between defaults and configuration overrides. Wrong: since you have to copy the whole file to override it, and files in /lib have no conffiles handling, after an upgrade you will not know what was changed by you and what was changed upstream. Obviously this is not a problem for Red Hat since they do not support upgrades between major releases. There are cases where file in /etc overrides only the directives present in /etc and not the rest. I prefer this way. -- Jean-Christophe Dubacq signature.asc Description: OpenPGP digital signature
Re: RFC: OpenRC as Init System for Debian
On Thu, 10 May 2012, Uoti Urpala wrote: You're pretty much just saying that dpkg and helpers like ucf have implemented better functionality than rpm. I don't see how that's relevant to the discussion. The reason why it is relevant is because in the etc-overrides-lib model you are unable to trivially merge local changes with upstream or packaging changes unless you add additional logic in the postinst to handle etc-overrides-lib. Having configuration files in /etc and using ucf or similar enables you to deal with this problem easily. Don Armstrong -- THERE IS NO GRAVITY THE WORLD SUCKS -- Vietnam War Penquin Lighter http://gallery.donarmstrong.com/clippings/vietnam_there_is_no_gravity.jpg http://www.donarmstrong.com http://rzlab.ucr.edu -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120510175506.gx3...@rzlab.ucr.edu
Re: RFC: OpenRC as Init System for Debian
On Thursday 10 May 2012 19:53:18 Uoti Urpala wrote: George Danchev wrote: On Thursday 10 May 2012 00:22:11 Uoti Urpala wrote: Steve McIntyre wrote: No, really - please *do* do this. The fact that a lot of the software coming out of RedHat development seems to be designed solely for their use, including working around the missing/broken features of RPM, is seriously annoying. Configuration belongs in /etc, we know this. We have a well-designed and implemented set of tools in Debian based on that standard. Machine-specific configuration belongs in /etc. The default behavior of the tools doesn't. For some reason or another the vast majority of applications have not been following this approach. I'm not going to argue whether is makes sense or not. The reason why most old applications do not follow that approach (at least not yet) is pretty obvious: their authors never considered it. etc-overrides-lib semantics have only become a seriously considered alternative fairly recently. Implying that a fairly simplistic semantics of providing two distinct directories with configuration files, has never been considered for the last 40 years and painting it as a revolution in the application development is naive, at best. Josh Triplett provided multiple technical reasons why etc-overrides-lib is preferable. The ONLY technical reason you gave to prefer traditional conffiles was that there already is a set of tools for that in Debian. Your comparison is misguided. Which comparison are you talking about? From your following text it seems you mean the comparison between 1) criticizing Red Hat for (allegedly) letting packaging system limitations affect the choice of configuration format and 2) saying Debian should choose its preferred configuration format based on the limitations of its packaging system, Let me tell you a secret: Debian should not decide whether or not tens of thousand of applications follow a particular style of reading their configuration files. This is in the realm of application development and anyone should be free to choose their style. It would be a segregation if Debian bans applications simply because their style of reading configuration files looks funny... and Debian does not segregate. This is not a secret. though that comparison does not appear in the text you quoted. The vast majority of applications do not follow etc-overrides-lib (some will never follow) so their configuration files should be properly managed as well, and dpkg's conffiles facility, dpkg's maintainer scripts in conjunction with things like ucf and debconf are quite powerful mechanisms to employ which have been proven for the last decade. Contrast this to the rpm systems trashing locally modified configuration files in /etc/ for the last decade. It is also trivial for the debian packages to contain default configuration files so users and tools could refer to them on demand, and this has nothing to do with the packaging system itself. You're pretty much just saying that dpkg and helpers like ucf have implemented better functionality than rpm. I don't see how that's relevant to the discussion. I don't think it makes the above comparison any less valid. And generally, I don't think the packaging system issues would be so difficult that they should have a major influence on what configuration model to use. What I was saying, I already wrote. Retelling it wrong is useless. OTOH, applications following etc-overrides-lib happily run on Debian systems in the way they run on others. It is not like the semantics of separating the default and locally modified configuration files in two directories is some sort of giant invention, never heard of before. It is also trivial to guess that their configuration files could also be managed by calling tools from dpkg's maintainer scripts in order to communicate with the user or provide assistance Yes, nobody has brought up reasons why this wouldn't work. Now, the hard work remains: teach all applcations out there to follow the etc- overrides-lib _semantics_. Sure, thing, I'm thrilled, at all. -- pub 4096R/0E4BD0AB people.fccf.net/danchev/key pgp.mit.edu -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201205102103.19021.danc...@spnet.net
Re: RFC: OpenRC as Init System for Debian
On 10/05/2012 19:55, Don Armstrong wrote: On Thu, 10 May 2012, Uoti Urpala wrote: You're pretty much just saying that dpkg and helpers like ucf have implemented better functionality than rpm. I don't see how that's relevant to the discussion. The reason why it is relevant is because in the etc-overrides-lib model you are unable to trivially merge local changes with upstream or packaging changes unless you add additional logic in the postinst to handle etc-overrides-lib. Having configuration files in /etc and using ucf or similar enables you to deal with this problem easily. Don Armstrong I do not know about trivially merging changes in the etc-overrides-lib model, but in the current model, I am presented with the dpkg prompt about conffiles for some programs where I added (or changed) only one line (off the top of my head: only the servers list in roundcube, for example), and dpkg does not propose to merge the two files: I am either stuck with keeping my old file, taking the new, or using a shell. All these things are interactive and prevent unattended upgrades without disruption of services. When the merging possibilities of dpkg will have been enhanced, I may reconsider, but currently, I prefer the etc-overrides-lib-only-where-present as superior to the current state. Sincerly, -- Jean-Christophe Dubacq signature.asc Description: OpenPGP digital signature
Re: RFC: OpenRC as Init System for Debian
On 05/10/2012 12:14 AM, Uoti Urpala wrote: Not having the files in /etc by default does have technical advantages. It's easier to see what is local non-default configuration. Original default file is always available in a known location (and very easy to revert to, temporarily for testing or permanently). Actually, what you are talking about is a very good candidate for /usr/share/doc/package/examples, not at all for a weird things with config files in /lib overridden by /etc, which really, isn't the Debian way. On 05/10/2012 12:14 AM, Uoti Urpala wrote: which in most cases is more maintainable than the 3-way merging required by traditional conffiles. The 3-way merging at least prompts you that something is changing so you have a chance to update your config file by hand the way you think is best. If the package updates the config file in /lib without prompting, then potentially, the user will not be aware of the change. In a RPM based environment, this behavior is fine, because that's the RPM way to never prompt anything to the user (see *.rpmsave or *.rpmnew files). But this is exactly why I don't like RPM systems! On 05/10/2012 12:14 AM, Uoti Urpala wrote: It's also preferable to avoid unnecessarily differing from the setup used on other distros. IMO, it's preferable to do things the same way on all packages in Debian. I don't see why systemd should be different from any other package we have in the Debian archve. If systemd can't adapt to our ways to do things, with configuration files in /etc, then I'm betting that many will complain (IMO rightly) about policy violation. (just my 2 cents, as I still have on my todo to try systemd...) Cheers, Thomas -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4fac0ab0.8040...@debian.org
Re: RFC: OpenRC as Init System for Debian
On 05/10/2012 04:52 AM, Steve McIntyre wrote: No, really - please *do* do this. The fact that a lot of the software coming out of RedHat development seems to be designed solely for their use, including working around the missing/broken features of RPM, is seriously annoying. Configuration belongs in /etc, we know this. We have a well-designed and implemented set of tools in Debian based on that standard. I agree 100% with the above. On 05/10/2012 05:22 AM, Uoti Urpala wrote: Josh Triplett provided multiple technical reasons why etc-overrides-lib is preferable. The ONLY technical reason you gave to prefer traditional conffiles was that there already is a set of tools for that in Debian. No, it's because this way, I am warned by the package manager of a change on the default file, and I can merge by hand when I see it. Otherwise, you are silently changing the default, and potentially, I will miss the new options. Besides this, configuration files in /etc is written in the stones of our bible^Wpolicy-manual. Thomas -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4fac0c9d.2070...@debian.org
Re: RFC: OpenRC as Init System for Debian
Marco d'Itri wrote: On May 10, Bjørn Mork bj...@mork.no wrote: Agree. Copying a large set of default policies into /etc just because they *can* be overridden is not user friendly. And it does not make the defaults any more configuration either. It just hides important local changes and makes it difficult both for the user and the application itself to distinguish between defaults and configuration overrides. Wrong: You're not addressing what he said about the generally desirable /etc semantics at all, only talking about what current Debian tools would do without modifications. Do you have a reason to oppose beyond this would need some tool changes? since you have to copy the whole file to override it, Wrong: as mentioned in this thread before, one of the advantages of the etc-overrides-lib model is the option of having a file in /etc that first includes the one in /lib, then overrides just one particular value. This allows handling more updates without needing manual changes, as you can automatically pick up other updated values while keeping the override, without needing to do 3-way merges. and files in /lib have no conffiles handling, after an upgrade you will not know what was changed by you and what was changed upstream. IIRC dpkg does not store the original file (while ucf does), so currently you always lose track of what was changed by you unless you make a copy manually (or with extra tools like etckeeper). Anyway, this is about the specifics of what is supported by Debian tools now, not about any intrinsic problem with the behavior. Obviously this is not a problem for Red Hat since they do not support upgrades between major releases. Why would this cause problems for Debian, except at most needing some changes to tools to better support this case? Or do you think implementing that would be hard? -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1336674656.2227.72.camel@glyph.nonexistent.invalid
Re: RFC: OpenRC as Init System for Debian
On Thu, 10 May 2012, David Weinehall wrote: On Wed, May 09, 2012 at 03:47:21PM +0200, Gergely Nagy wrote: Such a tool would certainly be very useful, but doing it right would be fairly hard, as far as I see. And it would require assistance from at least the package maintainer, to mark in which versions the unit file under /lib changed, so that it can trigger only when appropriate and not on every upgrade. (And there's possibly other corner cases to consider, but they escape me right now..) if [ file in etc -ot file in /lib ]; then warn user that updates might be needed fi That's not enough. The timestamp of the file in a package is unrelated to the time of its last installation. Cheers, -- Raphaël Hertzog ◈ Debian Developer Get the Debian Administrator's Handbook: → http://debian-handbook.info/get/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120510184745.ge8...@rivendell.home.ouaza.com
Re: RFC: OpenRC as Init System for Debian
On 05/10/2012 07:01 AM, Fernando Lemos wrote: I've seen people mention that the way udev and systemd do config files is really motivated by limitations in RH's packaging tools. Maybe that's the case, maybe not. It's *not*! It's a difference in *policy*. :) RH's policy is that you should never prompt the user for something when installing a package. We have debconf, ucf, etc. because we want the user to be prompted *if* he wants to (and I personally do want to, so I don't run in non-interactive mode). Thomas -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4fac0d9f.5070...@debian.org
