[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Better support for merging local and upstream (was: Erase cache, clean registry in Linux)

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

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

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

"Don't let them, daddy. Don't let the stars run down."

Reply to: