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
