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 default. 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 resolved. 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:
pgpUhQBxeZXPS.pgp
Description: PGP signature