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(a)0pointer.de> wrote:
> On Fri, 20.02.15 16:24, Peter Robinson (pbrobinson(a)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