Bug#939904: Temporary network disruption during upgrade
Le 21/08/2022 à 00:41, Luca Boccassi a écrit : Yes I noticed the same thing when building images, this cross-device check is a true annoyance and can't seem to find a workaround :-/ I can't find a solution, so unfortunately it looks like we have to resort to maintainer scripts, which is awful but I can't think of anything else: https://salsa.debian.org/systemd-team/systemd/-/merge_requests/164 Sorry to annoy you again, but... Why not just leave /etc/resolv.conf alone ? After all, shouldn't it be the user's choice to link it against /run/systemd/resolve/stub-resolv.conf, /run/systemd/resolve/resolv.conf, or just manage it manually ? Plus, it would solve both problems I mentioned before. Regards, -- Raphaël Halimi
Bug#939904: Temporary network disruption during upgrade
On Sat, 20 Aug 2022 20:30:43 +0100 Luca Boccassi wrote: > On Fri, 19 Aug 2022 08:58:03 +0200 Michael Prokop > wrote: > > Hi, > > > > * Luca Boccassi [Thu Aug 18, 2022 at 03:20:22PM +0100]: > > > On Thu, 2022-08-18 at 16:07 +0200, Raphaël Halimi wrote: > > > > > > And, last but not the least, I see that /etc/resolv.conf is now > part of > > > > systemd-resolved files, which means that it would be deleted when > the > > > > systemd-resolved package is removed from the system. I think it > would > > > > also deserve its own bug with some high priority > > > > > > No, that's working as intended - you remove one resolver, you need > to > > > install another one that provides it. > > > > I just tested a few things, JFYI: > > > > * When systemd-resolved is installed and gets removed, the > > file/symlink /etc/resolv.conf gets removed as well. Is that really > > expected? (This is something e.g. the resolvconf doesn't do, you > > still end up with a /etc/resolv.conf being in-place then) > > > > * Installation of the systemd-resolved package inside docker/podman > > fails hard for me (running on a Debian/bullseye host): > > > > | Unpacking systemd-resolved (251.4-1) ... > > | dpkg: error processing archive /var/cache/apt/archives/systemd- > resolved_251.4-1_amd64.deb (--unpack): > > | unable to make backup link of './etc/resolv.conf' before > installing new version: Invalid cross-device link > > | Selecting previously unselected package libnss-resolve:amd64. > > | Preparing to unpack .../libnss-resolve_251.4-1_amd64.deb ... > > | Unpacking libnss-resolve:amd64 (251.4-1) ... > > | Errors were encountered while processing: > > | /var/cache/apt/archives/systemd-resolved_251.4-1_amd64.deb > > | E: Sub-process /usr/bin/dpkg returned an error code (1) > > > > (Didn't investigate further on this yet, seems to be related to the > > way dpkg handles symlinks (as set up by dh_link in the systemd > > packaging) and containers with overlay doesn't like that, though > > installing systemd inside docker/podman containers used to work fine > > so far for me) > > > > HTH && regards > > -mika- > > Yes I noticed the same thing when building images, this cross-device > check is a true annoyance and can't seem to find a workaround :-/ I can't find a solution, so unfortunately it looks like we have to resort to maintainer scripts, which is awful but I can't think of anything else: https://salsa.debian.org/systemd-team/systemd/-/merge_requests/164 -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Bug#939904: Temporary network disruption during upgrade
On Fri, 19 Aug 2022 08:58:03 +0200 Michael Prokop wrote: > Hi, > > * Luca Boccassi [Thu Aug 18, 2022 at 03:20:22PM +0100]: > > On Thu, 2022-08-18 at 16:07 +0200, Raphaël Halimi wrote: > > > > And, last but not the least, I see that /etc/resolv.conf is now part of > > > systemd-resolved files, which means that it would be deleted when the > > > systemd-resolved package is removed from the system. I think it would > > > also deserve its own bug with some high priority > > > > No, that's working as intended - you remove one resolver, you need to > > install another one that provides it. > > I just tested a few things, JFYI: > > * When systemd-resolved is installed and gets removed, the > file/symlink /etc/resolv.conf gets removed as well. Is that really > expected? (This is something e.g. the resolvconf doesn't do, you > still end up with a /etc/resolv.conf being in-place then) > > * Installation of the systemd-resolved package inside docker/podman > fails hard for me (running on a Debian/bullseye host): > > | Unpacking systemd-resolved (251.4-1) ... > | dpkg: error processing archive /var/cache/apt/archives/systemd- resolved_251.4-1_amd64.deb (--unpack): > | unable to make backup link of './etc/resolv.conf' before installing new version: Invalid cross-device link > | Selecting previously unselected package libnss-resolve:amd64. > | Preparing to unpack .../libnss-resolve_251.4-1_amd64.deb ... > | Unpacking libnss-resolve:amd64 (251.4-1) ... > | Errors were encountered while processing: > | /var/cache/apt/archives/systemd-resolved_251.4-1_amd64.deb > | E: Sub-process /usr/bin/dpkg returned an error code (1) > > (Didn't investigate further on this yet, seems to be related to the > way dpkg handles symlinks (as set up by dh_link in the systemd > packaging) and containers with overlay doesn't like that, though > installing systemd inside docker/podman containers used to work fine > so far for me) > > HTH && regards > -mika- Yes I noticed the same thing when building images, this cross-device check is a true annoyance and can't seem to find a workaround :-/ -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Bug#939904: Temporary network disruption during upgrade
Le 18/08/2022 à 21:29, Luca Boccassi a écrit : Going for a custom setup means sometimes there is, sometimes there's not. It's always a tradeoff. This breaking change means there's now a supported way to run resolved, and it's the easiest possible way for all those that weren't using it before, which is the majority given there was no support and no integration before. I'll still file two separate bugs, one against systemd for the DNS resolution breakage after the upgrade, and the other one against systemd-resolved for the removal of /etc/resolv.conf after the package is removed. Even if you think there's no problem here, I don't agree and I think those are bugs, and serious ones at that. I'll file them just for the record, so feel free to immediately close them as wontfix, I won't mind. Regards, -- Raphaël Halimi
Bug#939904: Temporary network disruption during upgrade
Hi, * Luca Boccassi [Thu Aug 18, 2022 at 03:20:22PM +0100]: > On Thu, 2022-08-18 at 16:07 +0200, Raphaël Halimi wrote: > > And, last but not the least, I see that /etc/resolv.conf is now part of > > systemd-resolved files, which means that it would be deleted when the > > systemd-resolved package is removed from the system. I think it would > > also deserve its own bug with some high priority > > No, that's working as intended - you remove one resolver, you need to > install another one that provides it. I just tested a few things, JFYI: * When systemd-resolved is installed and gets removed, the file/symlink /etc/resolv.conf gets removed as well. Is that really expected? (This is something e.g. the resolvconf doesn't do, you still end up with a /etc/resolv.conf being in-place then) * Installation of the systemd-resolved package inside docker/podman fails hard for me (running on a Debian/bullseye host): | Unpacking systemd-resolved (251.4-1) ... | dpkg: error processing archive /var/cache/apt/archives/systemd-resolved_251.4-1_amd64.deb (--unpack): | unable to make backup link of './etc/resolv.conf' before installing new version: Invalid cross-device link | Selecting previously unselected package libnss-resolve:amd64. | Preparing to unpack .../libnss-resolve_251.4-1_amd64.deb ... | Unpacking libnss-resolve:amd64 (251.4-1) ... | Errors were encountered while processing: | /var/cache/apt/archives/systemd-resolved_251.4-1_amd64.deb | E: Sub-process /usr/bin/dpkg returned an error code (1) (Didn't investigate further on this yet, seems to be related to the way dpkg handles symlinks (as set up by dh_link in the systemd packaging) and containers with overlay doesn't like that, though installing systemd inside docker/podman containers used to work fine so far for me) HTH && regards -mika- signature.asc Description: PGP signature
Bug#939904: Temporary network disruption during upgrade
On Thu, 2022-08-18 at 18:07 +0200, Raphaël Halimi wrote: > Le 18/08/2022 à 16:59, Luca Boccassi a écrit : > > No, custom and unsupported setups are unsupported. Compatibility is > > provided for default environments, anything outside of it can and will > > break at any given time, and it's not really feasible to do otherwise > > given the uncountable amount of possible permutations. This time > > there's a clear and unambiguos NEWS entry with a notification, which > > doesn't even always happen. > > What I meant is that I thought systemd-networkd (which partly relies on > systemd-resolved) was considered supported since it was shipped with > systemd and thus installed by default (unlike, for example, netplan), > albeit not enabled. > > Should I understand that the only supported way to configure the network > in Debian is ifupdown with a plain /etc/resolv.conf file, and everything > outside of this scope is considered custom and thus, unsupported ? I'm > not being ironical here, it's a legitimate question. The default supported network configuration managers on Debian are NetworkManager for desktop environments (default brought in by Gnome, the default desktop env), and ifupdown (which is priority: important) for headless environments. > > > Wrong, I always receive e-mails with news as well as changelogs during > > > upgrades, with the more recent examples being on July 13, 22 and 25. I > > > don't know why it didn't work this time, but I can hardly believe that > > > it's apt-listchanges' fault. > > > > And yet it is, and it's been a known issue for quite some time: > > > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=977422 > > OK, you're right on this point, I didn't know that. Apologies. But it > also means that other sysadmins will be in the same case too when the > upgrade will take place (when bookworm is released, or when systemd > 251.3-2 will be backported to bullseye) and will have their DNS > resolution temporarily broken after the upgrade. > > But I guess you'll probably argue that it's their fault for using > systemd-resolved. NEWS files' main purpose is to communicate breaking changes, so I hope the issue in apt-listchanges is fixed before the release. Feel free to go bump the severity if you wish. I cannot do much about it. > > > I think you don't understand my position: I don't care about resolvconf > > > or openresolv, I just want to use systemd-resolved (not the systemd > > > resolvconf interface, but the systemd-resolved service itself!) and > > > avoid breakage during upgrades for all users. > > > > > > Look, I'm just trying to help here. You made a change, it has serious > > > consequences for systemd-resolved users, and I hinted them to you, > > > that's all. I think this is a bad change, but that's another matter. > > > Being obtuse and condescending won't help. > > > > Name-calling won't help either. > > Right, but at least admit that you're being a bit harsh to me since the > beginning of this thread, rejecting all my arguments and refusing to see > the problem here, basically saying that the resulting breakage is not > your fault and systemd-resolved users brought it on themselves by using > it because it's "unsupported". > > Again, I don't care about resolvconf or openresolv, I care about > sysadmins who use systemd-networkd/resolved on their servers or > containers, and I'm just trying to avoid problems for them as well as > for myself in the future. > > systemd brought a lot of controversy when it was adopted in Debian, and > I myself was amongst the people who were quite unhappy when it happened > (I still think that Jessie was too soon, it was not mature enough, but > that's another story). > > Now that we started to familiarize with its different parts and all in > all find it very convenient that they're installed by default, you > slowly remove them one by one (systemd-machined, systemd-timesyncd, > systemd-boot, and now systemd-resolved... Which will be the next ?), > forcing us sysadmins to constantly update our automated installation > procedures (debian-installer hooks, ansible/puppet recipes, container > images, etc etc), and defeating the very purpose of systemd to be "a > suite of basic building blocks for a Linux system" that we finally embraced. > > It's almost as if you want to discourage us to use the non-init-related > parts of systemd. Staying with a distro's default means there's almost always a seamless upgrade path when breaking changes happen, though not always. Going for a custom setup means sometimes there is, sometimes there's not. It's always a tradeoff. This breaking change means there's now a supported way to run resolved, and it's the easiest possible way for all those that weren't using it before, which is the majority given there was no support and no integration before. -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Bug#939904: Temporary network disruption during upgrade
Le 18/08/2022 à 16:59, Luca Boccassi a écrit : No, custom and unsupported setups are unsupported. Compatibility is provided for default environments, anything outside of it can and will break at any given time, and it's not really feasible to do otherwise given the uncountable amount of possible permutations. This time there's a clear and unambiguos NEWS entry with a notification, which doesn't even always happen. What I meant is that I thought systemd-networkd (which partly relies on systemd-resolved) was considered supported since it was shipped with systemd and thus installed by default (unlike, for example, netplan), albeit not enabled. Should I understand that the only supported way to configure the network in Debian is ifupdown with a plain /etc/resolv.conf file, and everything outside of this scope is considered custom and thus, unsupported ? I'm not being ironical here, it's a legitimate question. Wrong, I always receive e-mails with news as well as changelogs during upgrades, with the more recent examples being on July 13, 22 and 25. I don't know why it didn't work this time, but I can hardly believe that it's apt-listchanges' fault. And yet it is, and it's been a known issue for quite some time: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=977422 OK, you're right on this point, I didn't know that. Apologies. But it also means that other sysadmins will be in the same case too when the upgrade will take place (when bookworm is released, or when systemd 251.3-2 will be backported to bullseye) and will have their DNS resolution temporarily broken after the upgrade. But I guess you'll probably argue that it's their fault for using systemd-resolved. I think you don't understand my position: I don't care about resolvconf or openresolv, I just want to use systemd-resolved (not the systemd resolvconf interface, but the systemd-resolved service itself!) and avoid breakage during upgrades for all users. Look, I'm just trying to help here. You made a change, it has serious consequences for systemd-resolved users, and I hinted them to you, that's all. I think this is a bad change, but that's another matter. Being obtuse and condescending won't help. Name-calling won't help either. Right, but at least admit that you're being a bit harsh to me since the beginning of this thread, rejecting all my arguments and refusing to see the problem here, basically saying that the resulting breakage is not your fault and systemd-resolved users brought it on themselves by using it because it's "unsupported". Again, I don't care about resolvconf or openresolv, I care about sysadmins who use systemd-networkd/resolved on their servers or containers, and I'm just trying to avoid problems for them as well as for myself in the future. systemd brought a lot of controversy when it was adopted in Debian, and I myself was amongst the people who were quite unhappy when it happened (I still think that Jessie was too soon, it was not mature enough, but that's another story). Now that we started to familiarize with its different parts and all in all find it very convenient that they're installed by default, you slowly remove them one by one (systemd-machined, systemd-timesyncd, systemd-boot, and now systemd-resolved... Which will be the next ?), forcing us sysadmins to constantly update our automated installation procedures (debian-installer hooks, ansible/puppet recipes, container images, etc etc), and defeating the very purpose of systemd to be "a suite of basic building blocks for a Linux system" that we finally embraced. It's almost as if you want to discourage us to use the non-init-related parts of systemd. Regards, -- Raphaël Halimi
Bug#939904: Temporary network disruption during upgrade
On Thu, 2022-08-18 at 16:46 +0200, Raphaël Halimi wrote: > Le 18/08/2022 à 16:20, Luca Boccassi a écrit : > > No, it is not, because no integration nor support was provided before. > > It was an inhert and disabled service and binary. > > The NEWS file covers the change adequately for custom setups. Custom > > setups are always at risk of breakage. > > I agree that it was not enabled by default, but it was shipped by > systemd, with a stable interface, and as such, it was available for the > admin to use it if he/she wished. Breaking DNS resolution after an > upgrade is not a serious bug in your opinion ? No, custom and unsupported setups are unsupported. Compatibility is provided for default environments, anything outside of it can and will break at any given time, and it's not really feasible to do otherwise given the uncountable amount of possible permutations. This time there's a clear and unambiguos NEWS entry with a notification, which doesn't even always happen. > > That would make it de-facto the default resolver on Debian, and we > > really don't want that at this stage. There appears to be some bug in > > apt-listchanges when showing changelogs is enabled making it skip NEWS > > files if a changelog for the same version was already displayed, and > > there's not much we can do about it, it's a problem to be solved by > > apt-listchanges. > > Wrong, I always receive e-mails with news as well as changelogs during > upgrades, with the more recent examples being on July 13, 22 and 25. I > don't know why it didn't work this time, but I can hardly believe that > it's apt-listchanges' fault. And yet it is, and it's been a known issue for quite some time: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=977422 > > Absolutely not, the alternatives system is a gigantic mess that should > > have never existed in the first place. If you want to use openresolv, > > install openresolv and remove resolved. > > I think you don't understand my position: I don't care about resolvconf > or openresolv, I just want to use systemd-resolved (not the systemd > resolvconf interface, but the systemd-resolved service itself!) and > avoid breakage during upgrades for all users. > > Look, I'm just trying to help here. You made a change, it has serious > consequences for systemd-resolved users, and I hinted them to you, > that's all. I think this is a bad change, but that's another matter. > Being obtuse and condescending won't help. Name-calling won't help either. -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Bug#939904: Temporary network disruption during upgrade
Le 18/08/2022 à 16:20, Luca Boccassi a écrit : No, it is not, because no integration nor support was provided before. It was an inhert and disabled service and binary. The NEWS file covers the change adequately for custom setups. Custom setups are always at risk of breakage. I agree that it was not enabled by default, but it was shipped by systemd, with a stable interface, and as such, it was available for the admin to use it if he/she wished. Breaking DNS resolution after an upgrade is not a serious bug in your opinion ? That would make it de-facto the default resolver on Debian, and we really don't want that at this stage. There appears to be some bug in apt-listchanges when showing changelogs is enabled making it skip NEWS files if a changelog for the same version was already displayed, and there's not much we can do about it, it's a problem to be solved by apt-listchanges. Wrong, I always receive e-mails with news as well as changelogs during upgrades, with the more recent examples being on July 13, 22 and 25. I don't know why it didn't work this time, but I can hardly believe that it's apt-listchanges' fault. Absolutely not, the alternatives system is a gigantic mess that should have never existed in the first place. If you want to use openresolv, install openresolv and remove resolved. I think you don't understand my position: I don't care about resolvconf or openresolv, I just want to use systemd-resolved (not the systemd resolvconf interface, but the systemd-resolved service itself!) and avoid breakage during upgrades for all users. Look, I'm just trying to help here. You made a change, it has serious consequences for systemd-resolved users, and I hinted them to you, that's all. I think this is a bad change, but that's another matter. Being obtuse and condescending won't help. Regards, -- Raphaël Halimi
Bug#939904: Temporary network disruption during upgrade
On Thu, 2022-08-18 at 16:07 +0200, Raphaël Halimi wrote: > Le 17/08/2022 à 00:36, Luca Boccassi a écrit : > > > Personally I see this as a regression, since resolved used to be part of > > > systemd and thus readily available without installing additional packages. > > > > No support was provided before for resolved, it was completely inhert, > > hence it is not a regression. It is a change in behaviour, and thus > > noted in the NEWS file as expected. > > > > > Yes, but this goal could be achieved by letting resolved in the main > > > systemd package, and splitting only systemd-resolvconf in its own package. > > > > > > > Having a single-file-package that is confusing and harder to find is > > not something we want to do, unless there are extremely compelling > > reasons for it. Supporting resolvconf is not one. > > Could you at least address the temporary break in DNS resolution ? This > is still a serious bug, which would deserve its own bug with priority > grave (if not critical). Since systemd-resolved is mainly used on > servers, it could result in a very bad surprise for sysadmins when > bookworm is released. No, it is not, because no integration nor support was provided before. It was an inhert and disabled service and binary. The NEWS file covers the change adequately for custom setups. Custom setups are always at risk of breakage. > Perhaps it could be fixed by promoting systemd-resolved to a recommends > (instead of suggests) in systemd, so that it's installed during the > upgrade ? Or don't stop the service if /etc/resolv.conf is symlinked to > /run/systemd/resolve/stub-resolv.conf, so that the admin has the time to > read the NEWS entry (which, again, didn't work on my system, whereas it > was supposed to be sent in an e-mail by apt-listchanges), and install > systemd-resolved before rebooting ? That would make it de-facto the default resolver on Debian, and we really don't want that at this stage. There appears to be some bug in apt-listchanges when showing changelogs is enabled making it skip NEWS files if a changelog for the same version was already displayed, and there's not much we can do about it, it's a problem to be solved by apt-listchanges. > Also, I understand that you don't wish to revert your changes, but is > there a reason why resolvconf, openresolv and thus systemd-resolved > could coexist thanks to the alternatives system ? I know it would be > more work for maintainers of those three packages, but IMHO it would be > worth the effort. Absolutely not, the alternatives system is a gigantic mess that should have never existed in the first place. If you want to use openresolv, install openresolv and remove resolved. > And, last but not the least, I see that /etc/resolv.conf is now part of > systemd-resolved files, which means that it would be deleted when the > systemd-resolved package is removed from the system. I think it would > also deserve its own bug with some high priority No, that's working as intended - you remove one resolver, you need to install another one that provides it. -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Bug#939904: Temporary network disruption during upgrade
Le 17/08/2022 à 00:36, Luca Boccassi a écrit : Personally I see this as a regression, since resolved used to be part of systemd and thus readily available without installing additional packages. No support was provided before for resolved, it was completely inhert, hence it is not a regression. It is a change in behaviour, and thus noted in the NEWS file as expected. Yes, but this goal could be achieved by letting resolved in the main systemd package, and splitting only systemd-resolvconf in its own package. Having a single-file-package that is confusing and harder to find is not something we want to do, unless there are extremely compelling reasons for it. Supporting resolvconf is not one. Could you at least address the temporary break in DNS resolution ? This is still a serious bug, which would deserve its own bug with priority grave (if not critical). Since systemd-resolved is mainly used on servers, it could result in a very bad surprise for sysadmins when bookworm is released. Perhaps it could be fixed by promoting systemd-resolved to a recommends (instead of suggests) in systemd, so that it's installed during the upgrade ? Or don't stop the service if /etc/resolv.conf is symlinked to /run/systemd/resolve/stub-resolv.conf, so that the admin has the time to read the NEWS entry (which, again, didn't work on my system, whereas it was supposed to be sent in an e-mail by apt-listchanges), and install systemd-resolved before rebooting ? Also, I understand that you don't wish to revert your changes, but is there a reason why resolvconf, openresolv and thus systemd-resolved could coexist thanks to the alternatives system ? I know it would be more work for maintainers of those three packages, but IMHO it would be worth the effort. And, last but not the least, I see that /etc/resolv.conf is now part of systemd-resolved files, which means that it would be deleted when the systemd-resolved package is removed from the system. I think it would also deserve its own bug with some high priority. Regards, -- Raphaël Halimi
Bug#939904: Temporary network disruption during upgrade
On Tue, 2022-08-16 at 23:17 +0200, Raphaël Halimi wrote: > Le 16/08/2022 à 22:59, Luca Boccassi a écrit : > > You want resolved? Install the resolved package. Don't want resolved? > > Don't install the package. > > Personally I see this as a regression, since resolved used to be part of > systemd and thus readily available without installing additional packages. No support was provided before for resolved, it was completely inhert, hence it is not a regression. It is a change in behaviour, and thus noted in the NEWS file as expected. > > We do no want to support combining resolved with resolvconf - and in > > fact, the setup with conflicts+provides is exactly like other packages > > like openresolv are set up. > > Yes, but this goal could be achieved by letting resolved in the main > systemd package, and splitting only systemd-resolvconf in its own package. > Having a single-file-package that is confusing and harder to find is not something we want to do, unless there are extremely compelling reasons for it. Supporting resolvconf is not one. -- Kind regards, Luca Boccassi
Bug#939904: Temporary network disruption during upgrade
Le 16/08/2022 à 22:59, Luca Boccassi a écrit : You want resolved? Install the resolved package. Don't want resolved? Don't install the package. Personally I see this as a regression, since resolved used to be part of systemd and thus readily available without installing additional packages. We do no want to support combining resolved with resolvconf - and in fact, the setup with conflicts+provides is exactly like other packages like openresolv are set up. Yes, but this goal could be achieved by letting resolved in the main systemd package, and splitting only systemd-resolvconf in its own package. Regards, -- Raphaël Halimi
Bug#939904: Temporary network disruption during upgrade
On Sun, 14 Aug 2022 19:08:14 +0200 "Andrej Shadura" wrote: > Hi, > > On Sun, 14 Aug 2022, at 19:04, Michael Biebl wrote: > >> I agree that the decision should be revisited, but for a different > >> reason. I see no reason why resolvconf cannot be used with resolved; > >> OTOH the current split prevents that, which I find very undesirable. > >> > >> I was very surprised when I learnt today systemd-resolved has a > >> Conflicts against resolvconf, that was contrary to my expectations, and > >> I suspect I’m not the only person concerned about this. > >> > > > > Given that the package takes over management of /etc/resolv.conf, I > > don't think it makes sense to have resolvconf interfering here. > > > > tbh, I don't see the benefit/use case of installing resolvconf along > > side systemd-resolved. > > > But that's the point of the complaint, I'm afraid. Resolved doesn't have to take it over, it's just one of its operation modes. It's the mode we want to support and that provides the most value. We remove unused binaries and config from the main package, while keeping the new one as simple and straightforward as possible - no faffing around with maintainer scripts managing persistent filesystem changes, or weird optional toggles to figure out. You want resolved? Install the resolved package. Don't want resolved? Don't install the package. We do no want to support combining resolved with resolvconf - and in fact, the setup with conflicts+provides is exactly like other packages like openresolv are set up. -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Bug#939904: Temporary network disruption during upgrade
Hi, On Sun, 14 Aug 2022, at 19:04, Michael Biebl wrote: >> I agree that the decision should be revisited, but for a different >> reason. I see no reason why resolvconf cannot be used with resolved; >> OTOH the current split prevents that, which I find very undesirable. >> >> I was very surprised when I learnt today systemd-resolved has a >> Conflicts against resolvconf, that was contrary to my expectations, and >> I suspect I’m not the only person concerned about this. >> > > Given that the package takes over management of /etc/resolv.conf, I > don't think it makes sense to have resolvconf interfering here. > > tbh, I don't see the benefit/use case of installing resolvconf along > side systemd-resolved. But that's the point of the complaint, I'm afraid. Resolved doesn't have to take it over, it's just one of its operation modes. -- Cheers, Andrej
Bug#939904: Temporary network disruption during upgrade
Am 14.08.22 um 18:43 schrieb Andrej Shadura: Hi, On Sun, 14 Aug 2022 04:29:52 +0200 Raphaël Halimi wrote: And finally, my opinion: After reading the mail thread in this bug report, I thought the plan was to separate systemd-resolvconf (as Arch did, IIUC), not the entire systemd-resolved service. IMHO this is a **very** bad idea, and not only because of the broken DNS resolution broken after the upgrade in some cases... The whole point of systemd-resolved is that it's included in systemd (so basically in every Linux system nowadays) and, alongside systemd-networkd, provides an entire network configuration/management stack, without the need to install optional packages, but most importantly, standard across all distributions (no need to learn and/or master ifupdown, sysconfig, netplan, whatever, etc). If it's not too late, I strongly suggest to reintegrate systemd-resolved in the main systemd package (as it was before), and split only systemd-resolvconf. I agree that the decision should be revisited, but for a different reason. I see no reason why resolvconf cannot be used with resolved; OTOH the current split prevents that, which I find very undesirable. I was very surprised when I learnt today systemd-resolved has a Conflicts against resolvconf, that was contrary to my expectations, and I suspect I’m not the only person concerned about this. Given that the package takes over management of /etc/resolv.conf, I don't think it makes sense to have resolvconf interfering here. tbh, I don't see the benefit/use case of installing resolvconf along side systemd-resolved. OpenPGP_signature Description: OpenPGP digital signature
Bug#939904: Temporary network disruption during upgrade
Hi, On Sun, 14 Aug 2022 04:29:52 +0200 Raphaël Halimi wrote: And finally, my opinion: After reading the mail thread in this bug report, I thought the plan was to separate systemd-resolvconf (as Arch did, IIUC), not the entire systemd-resolved service. IMHO this is a **very** bad idea, and not only because of the broken DNS resolution broken after the upgrade in some cases... The whole point of systemd-resolved is that it's included in systemd (so basically in every Linux system nowadays) and, alongside systemd-networkd, provides an entire network configuration/management stack, without the need to install optional packages, but most importantly, standard across all distributions (no need to learn and/or master ifupdown, sysconfig, netplan, whatever, etc). If it's not too late, I strongly suggest to reintegrate systemd-resolved in the main systemd package (as it was before), and split only systemd-resolvconf. I agree that the decision should be revisited, but for a different reason. I see no reason why resolvconf cannot be used with resolved; OTOH the current split prevents that, which I find very undesirable. I was very surprised when I learnt today systemd-resolved has a Conflicts against resolvconf, that was contrary to my expectations, and I suspect I’m not the only person concerned about this. -- Cheers, Andrej
Bug#939904: Temporary network disruption during upgrade
Dear developers, I just upgraded a sid system and I noticed that the network was broken on this machine. I suppose the reason is that I had systemd-resolved enabled and /etc/resolv.conf was symlinked to the stub resolver (/run/systemd/resolve/stub-resolv.conf), and since the systemd-resolved service had disappeared and didn't respond anymore on 127.0.0.53, the system was left with a broken DNS resolution. On a side note, the changelog says that an entry was added in NEWS.Debian to warn user of the change, but it wasn't displayed during the upgrade (this is weird, I know). I had to read the changelog to understand what was going on. And finally, my opinion: After reading the mail thread in this bug report, I thought the plan was to separate systemd-resolvconf (as Arch did, IIUC), not the entire systemd-resolved service. IMHO this is a **very** bad idea, and not only because of the broken DNS resolution broken after the upgrade in some cases... The whole point of systemd-resolved is that it's included in systemd (so basically in every Linux system nowadays) and, alongside systemd-networkd, provides an entire network configuration/management stack, without the need to install optional packages, but most importantly, standard across all distributions (no need to learn and/or master ifupdown, sysconfig, netplan, whatever, etc). If it's not too late, I strongly suggest to reintegrate systemd-resolved in the main systemd package (as it was before), and split only systemd-resolvconf. Best regards, -- Raphaël Halimi
