1. Forum
  2. Usenet
  3. LINUX.DEBIAN.BUGS.DIST

  • Bug#1101532: marked as done (systemd: unable to migrate to Testing beca

    From Luca Boccassi@21:1/5 to mh+debian-packages@zugschlus.de on Wed Apr 2 11:20:01 2025
    On Wed, 2 Apr 2025 06:51:10 +0200 Marc Haber
    <mh+debian-packages@zugschlus.de> wrote:
    On Wed, Apr 02, 2025 at 12:24:02AM +0000, Debian Bug Tracking System
    wrote:
       * reintroduce systemd-resolved, with conflict on avahi-daemon. It
    turns
         out the cloud images have a hard dependency on resolved. In
    order to
         avoid having to change them, reintroduce the package, with a
    hard
         conflict on avahi-daemon to avoid reintroducing #1098914
    (Closes:
         #1101532)

    How would I configure my system when I want resolved to handle
    unicast
    DNS resolving (its features are rather nice, for example it handles gracefully when the first of the full service resolvers is down), but
    need avahi-daemon for service announcements?

    I might be stupid, but in my understanding the hard conflict forces
    me
    to have a local full service resolver running since I can't have systemd-resolved sans mDNS AND avahi-daemon. If my assumption is
    correct, the current solution breaks existing systems in a worse way
    than the solution proposed by the TC breaks other systems.

    Greetings
    Marc

    The problem is that, again, _something_ has to break. If it's not your
    use case, it's someone else's. Both are currently in use, in stable.
    One has to go.

    What am I supposed to do, exactly? I can't square a circle, I'm afraid

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Luca Boccassi@21:1/5 to Raphael Hertzog on Wed Apr 2 12:10:01 2025
    On Wed, 2 Apr 2025 at 10:38, Raphael Hertzog <hertzog@debian.org> wrote:

    Hi,

    On Wed, 02 Apr 2025 10:08:06 +0100 Luca Boccassi <bluca@debian.org> wrote:
    The problem is that, again, _something_ has to break. If it's not your
    use case, it's someone else's. Both are currently in use, in stable.
    One has to go.

    What am I supposed to do, exactly? I can't square a circle, I'm afraid

    I can answer that question: follow the decision of the technical committe which has already weighted the pros / cons of the various options.

    And then if you get blame from the persons experiencing the broken
    scenario, then you can say "sorry I just followed the decision of
    the tech-ctte" and not feel guilty.

    I am somewhat skeptical people suddenly having to deal with
    inaccessible remote machines will take much comfort in that. But ok,
    let's try that, at least that particular pleasantness is further down
    the road, rather than today.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)