systemd-219 issues with 22 and Rawhide composes

Pierre-Yves Chibon pingou at pingoured.fr
Mon Feb 23 14:01:47 UTC 2015


On Mon, Feb 23, 2015 at 08:45:56AM -0500, Nico Kadel-Garcia wrote:
> On Fri, Feb 20, 2015 at 11:36 AM, Lennart Poettering
> <mzerqung at 0pointer.de> wrote:
> > On Fri, 20.02.15 16:24, Peter Robinson (pbrobinson at gmail.com) wrote:
> >
> >> >> > Sorry for the inconvenience and feel free to add bugs to the tracker, which are
> >> >> > caused by systemd changes and have to be fixed in other components.
> >> >>
> >> >> Are you going to start notifying deve@ of upcoming changes that may
> >> >> impact other areas of the distro too rather than just land them
> >> >> without notification or discussion?
> >> >
> >> > Oh god, stop this, will you?
> >>
> >> No, I mean the above in general for general changes you make that
> >> affect the distro as a whole. You generally land them without
> >> notification.
> >
> > I "generally" do that? Can you be more precise?
> >
> >> > The folks in question knew I would drop the patch. In the original bug
> >> > I even said I would remove the work-around from systemd.rpm after TC1
> >> > of the last cycle. I was nice, left it in for the whole cycle, only
> >> > dropped it now.
> >>
> >> Yes, and it looks like it affects dhcpd too... just because you
> >> notified one dev team on a single bug it's not the same as a wider
> >> announcement to the wider community. There's all sorts of things that
> >> this can affect, and while yes it may be a bug in their software, it
> >> should be as widely notified as possible. People have priorities that
> >> may not be the same as yours.
> >
> > Hey! Come on. Everything that systemd does is create a symlink for
> > /etc/resolv.conf if nothing else has created on for that. If something
> > else created and owned that file, it leaves the thing alone. That's
> > all. It's very defensively written. Anaconda's file copy routine
> > tripped up on it though, since it follows symlinks on the destination
> > (which is a really bad idea, and needs to be fixed).
> 
> You do not know, and cannot know in advance without testing, how many
> different systems might manipulate or rely on specific resolv.conf
> changes. This is especially true for VPN based environments where the
> order of DNS resolvers is critical to correct local and general
> environment resolution. Puppet, cfengine, chef, tuttle, and many
> virtualization systems such manipulate entire network stacks by either
> stabilizing them or resetting them. And now they have to manipulate
> /etc/resolv.conf as a symlink?
> 
> It's one of the systemd problems: "We know better than the last 30
> years of UNIX work how this should be, and will take it over with our
> own unique, new paradigm."

There is no need to feed trolls on this list, thank you.

> >> > How many months would you like me to notify people in advance of a
> >> > simple change like this? Isn't 6 month *ample* time?
> >>
> >> Likely not, not everyone has the same schedule as upstream systemd, in
> >> a lot of cases they don't know it's broken until things land and teams
> >> have other priorities.
> >
> > OK, got it, will let everybody know now of changes 5 years in
> > advance. Would that suit your needs?
> 
> Only telling "the people who need to know" is the problem. You
> apparently think you know, personally, who those people are. That's
> not safe or fair to other developers or even to normal admins.
> 
> For example, now if I manipulate /etc/resolv.conf for whatever reason,
> and I edit it with "vi" or a management tool like "chef" that is
> unaware of symlinks, I'll break the link. Will systemd correctly
> re-establish the link? Will it wipe out my change, Did anyone even
> *think* about this?

And what makes you think it wasn't?
Did you face it yourself and report the bug upstream or are you assuming?
I hope for the former, otherwise you're just speculating and it is sad.

Pierre


More information about the devel mailing list