[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 Friday 2008 December 05 23:02, Stefan Monnier wrote:
> >>> Q: How are we going to do that?
> >>> A: It's not possible in general.
> >>
> >> Of course it is, since you can always fall back on the current code in
> >> those cases where you don't know how else to do it.
> >
> > No, it's not.
> > Falling back to the old behavior (not merging changes) is not a technique
> > for automatically merging local changes to conffiles.  It is refusing to
> > solve the problem, not a solution to the problem.
> 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.

Even if upstream packaging does not have this capability, Debian-specific 
patches can add it in.

> >>> When something is impossible, it's impractical to think about how it
> >>> would be done.
> >>
> >> Solving NP-hard problems in a reasonable amount of time is considered
> >> (currently and maybe for ever) impossible in general.  Yet, people write
> >> programs that do that every day.
> >
> > No, they don't.
> > Instead, they make take the general problem and make it more specific
> > through a set of assumptions.
> Right.  And that's exactly what I'm proposing: redefine the problem from
> "merge 100% automatically in all cases", to "do it in those cases where
> we know how to do it".  Suddenly your "impossible in general" becomes
> quite doable.

Using that definition, I'd say have the individual package maintainers do it.  
They'd be able to add more conffile-specific information to the process and 
be best equipped to judge when a merge will cause less problems than the 
alternative.  I'm not sure how this would tie into the standard conffile 
process, as conffiles aren't (IIRC) supposed to be modified/generated by the 
package, but rather a single conffile to to be shipped that is an acceptable 

It would be nice to have a choice of diffing tools, but diff3 and the like 
prefer having 3 copies: "orig", "yours", and "mine".  IIRC, by the time dpkg 
is prompting you, the original conffile is gone.  You've modified the 
installed version, and the old version of the package you are updating is 
generally not available.  So, you only have "mine" (current installed) 
and "yours" (version from package currently being installed).

I'm not sure the best way to provide an "orig".  I suppose you could install 
conffiles under something like /usr/.orig/<path> or just /.orig/<path>, 
with .orig and directories under it with 200 permissions and files under it 
having 400 permissions.  It probably wouldn't take up that much space and 
could be done automatically.  It would be a bit a annoying to have files on 
my / device that mirror those on my /usr or /var device, but not entirely 
unreasonable as long as the size is kept down.  This should, of course, be 
cleaned during a purge, and updated *after* the conflict(s), if any, are 

Why not write some patches against dpkg and float them out on debian-devel?  
I've got too much on my plate as is.
Boyd Stephen Smith Jr.                     ,= ,-_-. =. 
bss03@volumehost.net                      ((_/)o o(\_))
ICQ: 514984 YM/AIM: DaTwinkDaddy           `-'(. .)`-' 
http://iguanasuicide.org/                      \_/     

Attachment: pgpuykLvPEl8z.pgp
Description: PGP signature

Reply to: