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@xxxxxxxxxxx> wrote: > > On Fri, 20.02.15 16:24, Peter Robinson (pbrobinson@xxxxxxxxx) 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 -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
