On Sat, Dec 06, 2008 at 12:45:28AM -0600, Boyd Stephen Smith Jr. wrote: > On Friday 2008 December 05 23:02, Stefan Monnier wrote: > > When an upgrade is installed, local changes *have* to be merged with the > > changes brought in from the upgrade. That's just an unvoidable need. > > I disagree with this. It should be possible to establish "hooks" so that the > administrator should not ever have to edit an installed file, but instead > place additional or overriding instructions in a separate file which the > packages manager would not read or modify.
How exactly would that work? Think of /etc/exim4/exim4.conf, for example --- I'm already bypassing the automatic configuration because I was unable to figure out how to make it do what I want and because I don't want to use it because it's not human readable and editable and I wouldn't know how exactly exim is configured. To use the automatic configuration, you do not only need to know how to configure exim, you also would have to know how to use the automatic configuration to get it to create the configuration you want. That makes it at least twice as difficult to configure exim. Now, given that you use the automatic configuration, you want to add another level of difficulty by having another configuration to counteract the automatic configuration. Configuring exim would become at least three times as difficult as needed because you would have to learn how to configure exim, how to make the automatic configuration do what you want and then how to counteract the automatic configuration. Using /etc/exim4/exim4.conf is already providing "additional or overriding instructions" the package management doesn't touch. I wouldn't want package management software to interact in any way with my instructions, so merging something or having to provide only particular instructions against what the package management does is out of the question: It's easy to overlook something that the package management does which would require me to counteract it, especially when installing updates that might unexpectedly activate new features. With that kind of complexity, people will start asking if they can't go back to configure things themselves --- like they already do with exim. If I was serious about apache2, I would do the same for apache2, completely bypass the automatic stuff. Frankly, I don't know how the apache2 I'm running is configured because the automatic stuff hides the configuration from me. It's working, it doesn't matter much, but if it was an important service, I'd have to bypass the automatic system because I would need to know exactly what's configured. And it's the same as with exim: You'd have to know how to configure apache2, then you'd have to know how to make the automatic configuration create the configuration you want, and then you'd have to know which "additional or overriding instructions" you need to give. That's at least three times as difficult as just configuring apache2 yourself. The package management software just needs to tell you that it wants to make changes, what these changes would be and to give you the option to decide what you want. That's what it does now. If an update brings changes, I want to know what these changes are. I don't want them to be hidden from me by automatically changing or merging configurations. -- "Don't let them, daddy. Don't let the stars run down." http://adin.dyndns.org/adin/TheLastQ.htm -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
