Discussion:
systemd-219 issues with 22 and Rawhide composes
(too old to reply)
Harald Hoyer
2015-02-20 15:47:08 UTC
Permalink
To prevent surprises on the next systemd updates like in
<https://bugzilla.redhat.com/show_bug.cgi?id=1116651>, we will not apply
workarounds anymore in rawhide and track the issues on
<https://bugzilla.redhat.com/show_bug.cgi?id=systemd-other-tracker> so, that
they are not forgotten.

We removed the change for /etc/resolv.conf in F22 again (like in F21), but this
time we keep the change for rawhide.

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.
--
devel mailing list
***@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct:
Peter Robinson
2015-02-20 16:03:05 UTC
Permalink
Post by Harald Hoyer
To prevent surprises on the next systemd updates like in
<https://bugzilla.redhat.com/show_bug.cgi?id=1116651>, we will not apply
workarounds anymore in rawhide and track the issues on
<https://bugzilla.redhat.com/show_bug.cgi?id=systemd-other-tracker> so, that
they are not forgotten.
We removed the change for /etc/resolv.conf in F22 again (like in F21), but this
time we keep the change for rawhide.
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?

Peter
--
devel mailing list
***@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedorapr
Lennart Poettering
2015-02-20 16:11:58 UTC
Permalink
Post by Peter Robinson
Post by Harald Hoyer
To prevent surprises on the next systemd updates like in
<https://bugzilla.redhat.com/show_bug.cgi?id=1116651>, we will not apply
workarounds anymore in rawhide and track the issues on
<https://bugzilla.redhat.com/show_bug.cgi?id=systemd-other-tracker> so, that
they are not forgotten.
We removed the change for /etc/resolv.conf in F22 again (like in F21), but this
time we keep the change for rawhide.
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.
impact other areas of the distro too rather than just land them
without notification or discussion?
Oh god, stop this, will you?

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.

There is no news in all of this, I just removed the work-around now, as
indicated back then.

How many months would you like me to notify people in advance of a
simple change like this? Isn't 6 month *ample* time?

How much time do you think is appropriate for fixing a file copy
routine in anaconda? 12 months? 18 months? 2 years?

Also, NM fixed a similar issue with /etc/resolve.conf in their code a
long time ago, to my knowledge. Am I so misguided to assume that
Anaconda can fix a fricking file copy too, in all those months?

Lennart
--
Lennart Poettering, Red Hat
--
devel mailing list
***@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: h
Peter Robinson
2015-02-20 16:24:36 UTC
Permalink
On Fri, Feb 20, 2015 at 4:11 PM, Lennart Poettering
Post by Lennart Poettering
Post by Peter Robinson
Post by Harald Hoyer
To prevent surprises on the next systemd updates like in
<https://bugzilla.redhat.com/show_bug.cgi?id=1116651>, we will not apply
workarounds anymore in rawhide and track the issues on
<https://bugzilla.redhat.com/show_bug.cgi?id=systemd-other-tracker> so, that
they are not forgotten.
We removed the change for /etc/resolv.conf in F22 again (like in F21), but this
time we keep the change for rawhide.
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.
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.
Post by Lennart Poettering
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.
Post by Lennart Poettering
There is no news in all of this, I just removed the work-around now, as
indicated back then.
Again, I'm not just referring to this single incident, it would be
nice if you notified people widely of changes. It's a community,
people don't all follow closely the upstream development of all
upstream components.
Post by Lennart Poettering
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.
Post by Lennart Poettering
How much time do you think is appropriate for fixing a file copy
routine in anaconda? 12 months? 18 months? 2 years?
I'm not just referring to *just* anaconda. This is *one* thing,
there's other things that might be broken by this. How long has
/etc/resolv.conf been a file in that location? How many things across
the distro expect it to be like it is? It's legacy and while I'm not
against changing it there may be impact that isn't take into account.
Bullying people/process/team just because "you've waited 6 months
already" isn't an appropriate response just because you're impatient
and want to move on. We're a community that doesn't revolved around
systemd... sorry!
Post by Lennart Poettering
Also, NM fixed a similar issue with /etc/resolve.conf in their code a
long time ago, to my knowledge. Am I so misguided to assume that
Anaconda can fix a fricking file copy too, in all those months?
To my knowledge there also looks to be issues with dhcp due to this
change as of yesterday.... so maybe you don't have all the knowledge.
What else might be affected in the distro according "to your
knowledge"?

Peter
--
devel mailing list
***@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http:
Lennart Poettering
2015-02-20 16:36:17 UTC
Permalink
Post by Peter Robinson
Post by Lennart Poettering
Post by Peter Robinson
Post by Harald Hoyer
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.
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?
Post by Peter Robinson
Post by Lennart Poettering
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).
Post by Peter Robinson
Post by Lennart Poettering
There is no news in all of this, I just removed the work-around now, as
indicated back then.
Again, I'm not just referring to this single incident, it would be
nice if you notified people widely of changes. It's a community,
people don't all follow closely the upstream development of all
upstream components.
Ok, then please list all those numerous incidents please.
Post by Peter Robinson
Post by Lennart Poettering
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?

Anyway, I have the suspicion you just want to make a fuss, and this is
where it ends for me hence.

Good night,

Lennart
--
Lennart Poettering, Red Hat
--
devel mailing list
***@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-co
Peter Robinson
2015-02-20 16:52:20 UTC
Permalink
Post by Lennart Poettering
Post by Peter Robinson
Post by Lennart Poettering
Post by Peter Robinson
Post by Harald Hoyer
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.
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?
Post by Peter Robinson
Post by Lennart Poettering
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).
Post by Peter Robinson
Post by Lennart Poettering
There is no news in all of this, I just removed the work-around now, as
indicated back then.
Again, I'm not just referring to this single incident, it would be
nice if you notified people widely of changes. It's a community,
people don't all follow closely the upstream development of all
upstream components.
Ok, then please list all those numerous incidents please.
Post by Peter Robinson
Post by Lennart Poettering
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?
Not what I'm saying at all. There's no need to throw toys to the
extreme just because someone is asking for a certain level of reason
and engagement.
Post by Lennart Poettering
Anyway, I have the suspicion you just want to make a fuss, and this is
where it ends for me hence.
Nope, I don't, I just want engagement, generally and overall I'm
actively positive for systemd and a big advocate for it. You just need
to engage in the community and if something isn't done in six months
because another team has other priorities and other deadlines and
people push back because it's actually breaking other areas of the
distribution there's no need to throw toys from the pram and storm
off. It's a large distro of moving parts and we need flexibility as a
result, things get pushed due to delays. It's not the end of the
world!

Peter
--
devel mailing list
***@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproje
Paul W. Frields
2015-02-20 17:13:09 UTC
Permalink
Post by Peter Robinson
Post by Lennart Poettering
Post by Peter Robinson
Post by Lennart Poettering
Post by Peter Robinson
Post by Harald Hoyer
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.
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?
Post by Peter Robinson
Post by Lennart Poettering
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).
Post by Peter Robinson
Post by Lennart Poettering
There is no news in all of this, I just removed the work-around now, as
indicated back then.
Again, I'm not just referring to this single incident, it would be
nice if you notified people widely of changes. It's a community,
people don't all follow closely the upstream development of all
upstream components.
Ok, then please list all those numerous incidents please.
Post by Peter Robinson
Post by Lennart Poettering
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?
Not what I'm saying at all. There's no need to throw toys to the
extreme just because someone is asking for a certain level of reason
and engagement.
Post by Lennart Poettering
Anyway, I have the suspicion you just want to make a fuss, and this is
where it ends for me hence.
Nope, I don't, I just want engagement, generally and overall I'm
actively positive for systemd and a big advocate for it. You just need
to engage in the community and if something isn't done in six months
because another team has other priorities and other deadlines and
people push back because it's actually breaking other areas of the
distribution there's no need to throw toys from the pram and storm
off. It's a large distro of moving parts and we need flexibility as a
result, things get pushed due to delays. It's not the end of the
world!
I think we can do better than this level of communication. Yes, it
would have been good to avoid a surprise here. There are issues on
both sides. Blaming the situation on either impatience or sloth
doesn't do any justice to the good efforts everyone makes.

On one side, it may not be reasonable to expect that all teams track
or follow up on every bug. It's right to expect some explicit notice
and, more importantly, collaboration across teams -- talking to each
other, not just filing a bug without clear expectations.

On the other hand, Fedora is supposed to be innovative and we need to
take a positive approach to change. When teams see a change coming up
they know will cause them work or breakage, they can proactively reach
out to engage. In fact, anyone can facilitate such a conversation.

Also, a side note: A book I read on communication in relationships
once (I think it was "That's Not What I Meant" by Deborah Tannen) said
that when one universalizes statements, e.g. "you usually do <X>" or
"you always do <Y>," it's unlikely to yield any positive results in a
discussion. I've seen nothing in open source communication that gives
evidence to the contrary. :-) The important thing is that we try to
deal constructively with this specific situation, and in learning from
it, we can mitigate similar situations in the future.
--
Paul W. Frields <***@redhat.com>
Manager, Fedora Engineering - Emerging Platform
http://redhat.com -- http://opensource.com
--
devel mailing list
***@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code
Dennis Gilmore
2015-02-20 17:04:13 UTC
Permalink
On Fri, 20 Feb 2015 17:36:17 +0100
Post by Lennart Poettering
Post by Peter Robinson
Post by Lennart Poettering
Post by Harald Hoyer
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.
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?
A recent example, systemd decided that os-release needed to be moved
to /usr/lib/ I did not see any notification on devel@ nor was i
contacted directly. the first I heard of it was a third party person
filing a bug against fedora-release

Dennis
--
devel mailing list
***@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-co
Dennis Gilmore
2015-02-20 17:07:51 UTC
Permalink
On Fri, 20 Feb 2015 11:04:13 -0600
Post by Dennis Gilmore
On Fri, 20 Feb 2015 17:36:17 +0100
Post by Lennart Poettering
Post by Peter Robinson
Post by Lennart Poettering
Post by Harald Hoyer
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.
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?
A recent example, systemd decided that os-release needed to be moved
contacted directly. the first I heard of it was a third party person
filing a bug against fedora-release
I should add that changing it broke the compose process and was quickly
fixed. wider communication means that other effected components have
some visibility into things that may effect them.

Dennis
--
devel mailing list
***@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: ht
Lennart Poettering
2015-02-20 17:12:29 UTC
Permalink
Post by Dennis Gilmore
On Fri, 20 Feb 2015 11:04:13 -0600
Post by Dennis Gilmore
On Fri, 20 Feb 2015 17:36:17 +0100
Post by Lennart Poettering
Post by Peter Robinson
Post by Lennart Poettering
Post by Harald Hoyer
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.
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?
A recent example, systemd decided that os-release needed to be moved
contacted directly. the first I heard of it was a third party person
filing a bug against fedora-release
I should add that changing it broke the compose process and was quickly
fixed. wider communication means that other effected components have
some visibility into things that may effect them.
You cannot really blame me for breakages for things I neither asked
for nor was involved with at all in Fedora.

Lennart
--
Lennart Poettering, Red Hat
--
devel mailing list
***@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedo
Dennis Gilmore
2015-02-20 17:49:41 UTC
Permalink
On Fri, 20 Feb 2015 18:12:29 +0100
Post by Lennart Poettering
Post by Dennis Gilmore
On Fri, 20 Feb 2015 11:04:13 -0600
Post by Dennis Gilmore
On Fri, 20 Feb 2015 17:36:17 +0100
Post by Lennart Poettering
Post by Peter Robinson
Post by Lennart Poettering
Post by Harald Hoyer
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.
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?
A recent example, systemd decided that os-release needed to be
was i contacted directly. the first I heard of it was a third
party person filing a bug against fedora-release
I should add that changing it broke the compose process and was
quickly fixed. wider communication means that other effected
components have some visibility into things that may effect them.
You cannot really blame me for breakages for things I neither asked
for nor was involved with at all in Fedora.
Lennart
I am not blaming you for anything here, merely pointing out that if
there was better communications we could have likely avoided the
breakage while the change was made altogether.

Dennis
--
devel mailing list
***@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.or
Lennart Poettering
2015-02-23 12:24:11 UTC
Permalink
Post by Dennis Gilmore
Post by Lennart Poettering
Post by Dennis Gilmore
Post by Dennis Gilmore
A recent example, systemd decided that os-release needed to be
was i contacted directly. the first I heard of it was a third
party person filing a bug against fedora-release
I should add that changing it broke the compose process and was
quickly fixed. wider communication means that other effected
components have some visibility into things that may effect them.
You cannot really blame me for breakages for things I neither asked
for nor was involved with at all in Fedora.
I am not blaming you for anything here, merely pointing out that if
there was better communications we could have likely avoided the
breakage while the change was made altogether.
Good, please ping me about changes like this next time then, and I am
happy to comment!

Lennart
--
Lennart Poettering, Red Hat
--
devel mailing list
***@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedor
Lennart Poettering
2015-02-20 17:11:38 UTC
Permalink
Post by Dennis Gilmore
On Fri, 20 Feb 2015 17:36:17 +0100
Post by Lennart Poettering
Post by Peter Robinson
Post by Lennart Poettering
Post by Harald Hoyer
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.
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?
A recent example, systemd decided that os-release needed to be moved
contacted directly. the first I heard of it was a third party person
filing a bug against fedora-release
While moving it is great, it's not really that important to move it.

I mean, moving it is useful in the context of stateless systems that
can boot up with empty /etc. However, Fedora is so far away from that,
that we have tons of other things to fix first, before the os-release
move would start to matter.

We haven't posted a feature to make Fedora stateless in this sense,
and hence also didn't ask for /etc/os-release to be moved. There are
some upstream things to work on before we can propose such a Fedora
change.

So, thank you very much for moving it! But this is neither a change
that would really need coordination, nor something we pushed for from
our side.

Lennart
--
Lennart Poettering, Red Hat
--
devel mailing list
***@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedo
Dennis Gilmore
2015-02-20 17:48:18 UTC
Permalink
On Fri, 20 Feb 2015 18:11:38 +0100
Post by Lennart Poettering
Post by Dennis Gilmore
On Fri, 20 Feb 2015 17:36:17 +0100
Post by Lennart Poettering
Post by Peter Robinson
Post by Lennart Poettering
Post by Harald Hoyer
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.
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?
A recent example, systemd decided that os-release needed to be moved
contacted directly. the first I heard of it was a third party person
filing a bug against fedora-release
While moving it is great, it's not really that important to move it.
I mean, moving it is useful in the context of stateless systems that
can boot up with empty /etc. However, Fedora is so far away from that,
that we have tons of other things to fix first, before the os-release
move would start to matter.
We haven't posted a feature to make Fedora stateless in this sense,
and hence also didn't ask for /etc/os-release to be moved. There are
some upstream things to work on before we can propose such a Fedora
change.
So, thank you very much for moving it! But this is neither a change
that would really need coordination, nor something we pushed for from
our side.
communication would have avoided some of the discussion in
https://bugzilla.redhat.com/show_bug.cgi?id=1149568 and likely avoided
having the bug altogether. regardless of your reasons for making a
change or how unimportant you consider it, others follow things that are
done and follow up on them when you do not. I for one would appreciate
knowing when the allowable fields change in os-release because the
first I ever hear is when people file bugs asking for them to be added
to Fedora. I then have to chase things down to catch up.

Dennis
--
devel mailing list
***@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedora
Colin Walters
2015-02-20 17:52:08 UTC
Permalink
Post by Dennis Gilmore
communication would have avoided some of the discussion in
https://bugzilla.redhat.com/show_bug.cgi?id=1149568
Which btw, caused

https://bugzilla.redhat.com/show_bug.cgi?id=1192276

Could you review?
I'm fixing this in OSTree too, https://github.com/GNOME/ostree/pull/59
but it'd be nice to fix it two ways, and relative symlinks are generally
nicer than absolute.
--
devel mailing list
***@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://
Lennart Poettering
2015-02-23 12:23:01 UTC
Permalink
Post by Dennis Gilmore
Post by Lennart Poettering
While moving it is great, it's not really that important to move it.
I mean, moving it is useful in the context of stateless systems that
can boot up with empty /etc. However, Fedora is so far away from that,
that we have tons of other things to fix first, before the os-release
move would start to matter.
We haven't posted a feature to make Fedora stateless in this sense,
and hence also didn't ask for /etc/os-release to be moved. There are
some upstream things to work on before we can propose such a Fedora
change.
So, thank you very much for moving it! But this is neither a change
that would really need coordination, nor something we pushed for from
our side.
communication would have avoided some of the discussion in
https://bugzilla.redhat.com/show_bug.cgi?id=1149568 and likely avoided
having the bug altogether. regardless of your reasons for making a
change or how unimportant you consider it, others follow things that are
done and follow up on them when you do not. I for one would appreciate
knowing when the allowable fields change in os-release because the
first I ever hear is when people file bugs asking for them to be added
to Fedora. I then have to chase things down to catch up.
Communication is a two way street, and as an upstream I cannot be in
the business of pinging every single downstream about every single
change individually, in particular if I consider the change
unimportant.

To learn about changes upstream, please follow the upstream
discussions, thank you.

Lennart
--
Lennart Poettering, Red Hat
--
devel mailing list
***@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: h
David Cantrell
2015-02-23 13:17:30 UTC
Permalink
Post by Lennart Poettering
Post by Dennis Gilmore
Post by Lennart Poettering
While moving it is great, it's not really that important to move it.
I mean, moving it is useful in the context of stateless systems that
can boot up with empty /etc. However, Fedora is so far away from that,
that we have tons of other things to fix first, before the os-release
move would start to matter.
We haven't posted a feature to make Fedora stateless in this sense,
and hence also didn't ask for /etc/os-release to be moved. There are
some upstream things to work on before we can propose such a Fedora
change.
So, thank you very much for moving it! But this is neither a change
that would really need coordination, nor something we pushed for from
our side.
communication would have avoided some of the discussion in
https://bugzilla.redhat.com/show_bug.cgi?id=1149568 and likely avoided
having the bug altogether. regardless of your reasons for making a
change or how unimportant you consider it, others follow things that are
done and follow up on them when you do not. I for one would appreciate
knowing when the allowable fields change in os-release because the
first I ever hear is when people file bugs asking for them to be added
to Fedora. I then have to chase things down to catch up.
Communication is a two way street, and as an upstream I cannot be in
the business of pinging every single downstream about every single
change individually, in particular if I consider the change
unimportant.
To learn about changes upstream, please follow the upstream
discussions, thank you.
This still fails. The expectation here is that downstream consumers know an
upstream change is coming. As evidenced by the various bugs mentioned in
this thread, the result is "surprise, something changed". So the discovery
is reactionary rather than coordinated before putting a change in rawhide.

It would be a slightly different story if rawhide's systemd was gated by
someone doing Fedora integration coordination, but it doesn't appear anyone
is doing that. And you say you can't, though I am disappointed with that
since you sort of kind of already signed up for that work by starting
systemd and getting it in to Fedora in the first place. If it's not you
that coordinates this work, someone who works on and/or maintains the
systemd package in Fedora should be doing this. That is, and I am trying to
be specific here, changes that impact other components in the distribution
need to be coordinated in Fedora among the affected components.
--
David Cantrell <***@redhat.com>
Manager, Installer Engineering Team
Red Hat, Inc. | Westford, MA | EST5EDT
--
devel mailing list
***@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-
drago01
2015-02-23 13:40:28 UTC
Permalink
Post by David Cantrell
That is, and I am trying to
be specific here, changes that impact other components in the distribution
need to be coordinated in Fedora among the affected components.
Almost every change might "affect other components" ... it might be
obvious to a maintainer of an affected component but not necessarily
for the maintainer / developer of the component that got changed.
--
devel mailing list
***@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduc
Simo Sorce
2015-02-23 13:52:36 UTC
Permalink
Post by drago01
Post by David Cantrell
That is, and I am trying to
be specific here, changes that impact other components in the distribution
need to be coordinated in Fedora among the affected components.
Almost every change might "affect other components" ... it might be
obvious to a maintainer of an affected component but not necessarily
for the maintainer / developer of the component that got changed.
Which is why you should send a message to a general development list for
changes that change the semantics of a well established mechanism.

If you are changing something internal to your software then the burden
of keeping up is with the downstream people that may decide to depend on
internal features (assuming private/public interfaces are clearly
defined).

If you are changing something in the system public interfaces, instead a
bit more general and advance notice is necessary.

This is a general rule, not specific to systemd, and I am guilty of
having changed stuff without a direct message to devel@ in the past.

We all need to get better at communicating changes that may affect
others, it buys goodwill and understanding, and perhaps the occasional
flame, but what was the saying ? Flame early, flame often ? :)

Simo.
--
Simo Sorce * Red Hat, Inc * New York
--
devel mailing list
***@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://f
Lennart Poettering
2015-02-23 15:29:42 UTC
Permalink
Post by Simo Sorce
Post by drago01
Post by David Cantrell
That is, and I am trying to
be specific here, changes that impact other components in the distribution
need to be coordinated in Fedora among the affected components.
Almost every change might "affect other components" ... it might be
obvious to a maintainer of an affected component but not necessarily
for the maintainer / developer of the component that got changed.
Which is why you should send a message to a general development list for
changes that change the semantics of a well established mechanism.
If you are changing something internal to your software then the burden
of keeping up is with the downstream people that may decide to depend on
internal features (assuming private/public interfaces are clearly
defined).
If you are changing something in the system public interfaces, instead a
bit more general and advance notice is necessary.
The /etc/os-release to /usr/lib/os-release is hardly a change in the
public interface, it keeps compat by leaving a symlink in /etc.

And jeezuz, I didn't push this change into Fedora. Other people did,
without talking to me.

Really, this is neither much of a compat break, nor is this something
I even knew about. Really, find something else to complain about.

Lennart
--
Lennart Poettering, Red Hat
--
devel mailing list
***@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http:
Simo Sorce
2015-02-23 16:11:00 UTC
Permalink
Post by Lennart Poettering
Post by Simo Sorce
Post by drago01
Post by David Cantrell
That is, and I am trying to
be specific here, changes that impact other components in the distribution
need to be coordinated in Fedora among the affected components.
Almost every change might "affect other components" ... it might be
obvious to a maintainer of an affected component but not necessarily
for the maintainer / developer of the component that got changed.
Which is why you should send a message to a general development list for
changes that change the semantics of a well established mechanism.
If you are changing something internal to your software then the burden
of keeping up is with the downstream people that may decide to depend on
internal features (assuming private/public interfaces are clearly
defined).
If you are changing something in the system public interfaces, instead a
bit more general and advance notice is necessary.
The /etc/os-release to /usr/lib/os-release is hardly a change in the
public interface, it keeps compat by leaving a symlink in /etc.
And jeezuz, I didn't push this change into Fedora. Other people did,
without talking to me.
Really, this is neither much of a compat break, nor is this something
I even knew about. Really, find something else to complain about.
If you want to whine for something, at least whine at those that are
accusing you of having done something.

In my message I accused nobody and made a mea cupla as much as anything.

Context boy!

Simo.
--
Simo Sorce * Red Hat, Inc * New York
--
devel mailing list
***@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraprojec
Lennart Poettering
2015-02-23 15:27:22 UTC
Permalink
Post by David Cantrell
Post by Lennart Poettering
Communication is a two way street, and as an upstream I cannot be in
the business of pinging every single downstream about every single
change individually, in particular if I consider the change
unimportant.
To learn about changes upstream, please follow the upstream
discussions, thank you.
This still fails. The expectation here is that downstream consumers know an
upstream change is coming. As evidenced by the various bugs mentioned in
this thread, the result is "surprise, something changed". So the discovery
is reactionary rather than coordinated before putting a change in rawhide.
Hey, there was no need for Fedora to change the path for
/etc/os-release. It was good that it decided to change, but this was
done without contacting me, and I didn't push for it, I was not
involved at all really, and I cannot read people's minds about it. The
change is nothing that would normally considered an "incompatible
change", it just moved one file from /etc to /usr/lib and replaced it
with a symlink.

Please find something else to complain about. THis particular case
makes a really bad example, since I was hardly involved, it wasn't my
side that was communicating badly, but the folks adding this to
Fedora, and that wasn't me.
Post by David Cantrell
It would be a slightly different story if rawhide's systemd was gated by
someone doing Fedora integration coordination, but it doesn't appear anyone
is doing that. And you say you can't, though I am disappointed with that
since you sort of kind of already signed up for that work by starting
systemd and getting it in to Fedora in the first place. If it's not you
that coordinates this work, someone who works on and/or maintains the
systemd package in Fedora should be doing this. That is, and I am trying to
be specific here, changes that impact other components in the distribution
need to be coordinated in Fedora among the affected components.
David, I see how you would like to pin this all on systemd's
supposedly bad communication. But coming back to the /etc/resolv.conf
issue: it really just boils down to the fact that you knew the change
was coming 6 months ago, but instead of making the necessary one-line
fix in your packages, you didn't do anything.

Lennart
--
Lennart Poettering, Red Hat
--
devel mailing list
***@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Co
David Cantrell
2015-02-23 15:52:38 UTC
Permalink
Post by Lennart Poettering
Post by David Cantrell
Post by Lennart Poettering
Communication is a two way street, and as an upstream I cannot be in
the business of pinging every single downstream about every single
change individually, in particular if I consider the change
unimportant.
To learn about changes upstream, please follow the upstream
discussions, thank you.
This still fails. The expectation here is that downstream consumers know an
upstream change is coming. As evidenced by the various bugs mentioned in
this thread, the result is "surprise, something changed". So the discovery
is reactionary rather than coordinated before putting a change in rawhide.
Hey, there was no need for Fedora to change the path for
/etc/os-release. It was good that it decided to change, but this was
done without contacting me, and I didn't push for it, I was not
involved at all really, and I cannot read people's minds about it. The
change is nothing that would normally considered an "incompatible
change", it just moved one file from /etc to /usr/lib and replaced it
with a symlink.
Please find something else to complain about. THis particular case
makes a really bad example, since I was hardly involved, it wasn't my
side that was communicating badly, but the folks adding this to
Fedora, and that wasn't me.
Are you the owner of systemd or not? You travel the world giving talks
about it, yet when confronted with problems caused by changes in systemd you
point to others and say it's not you. What is it? Either you have a stake
in systemd or not.
Post by Lennart Poettering
Post by David Cantrell
It would be a slightly different story if rawhide's systemd was gated by
someone doing Fedora integration coordination, but it doesn't appear anyone
is doing that. And you say you can't, though I am disappointed with that
since you sort of kind of already signed up for that work by starting
systemd and getting it in to Fedora in the first place. If it's not you
that coordinates this work, someone who works on and/or maintains the
systemd package in Fedora should be doing this. That is, and I am trying to
be specific here, changes that impact other components in the distribution
need to be coordinated in Fedora among the affected components.
David, I see how you would like to pin this all on systemd's
supposedly bad communication. But coming back to the /etc/resolv.conf
issue: it really just boils down to the fact that you knew the change
was coming 6 months ago, but instead of making the necessary one-line
fix in your packages, you didn't do anything.
OK, if we're speaking specifically about this, what a change like this
requires is a heads-up when you are going to commit the change to rawhide.
That's it. A six month old bug doesn't count. Fine, we knew about it via
the filed bug, but we don't know WHEN you'll be pushing the change. And
even if you did mention exactly when that would happen, a heads up to teams
to remind them to make their changes is super helpful. Again, *you* are the
one who knows this is coming more precisely than we do.

Your insistence on not taking responsibility for problems that you directly
cause is frustrating. And many people have pointed this out. You are very
quick to immediately distance yourself from conflicts caused by systemd by
raising any number of flags, such as "it's Fedora, not me" or "that was an
upstream decision, Fedora doesn't have to follow it". Come on, seriously?
Fedora is all about maximum upstream cooperation and usage, so you cannot
seriously think you can distance yourself from Fedora that much.

All we want is BETTER COMMUNICATION from you within this project. This
project being Fedora. Be a team player, please.
--
David Cantrell <***@redhat.com>
Manager, Installer Engineering Team
Red Hat, Inc. | Westford, MA | EST5EDT
--
devel mailing list
***@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/cod
Lennart Poettering
2015-02-23 16:13:53 UTC
Permalink
Post by David Cantrell
Post by Lennart Poettering
Post by David Cantrell
Post by Lennart Poettering
Communication is a two way street, and as an upstream I cannot be in
the business of pinging every single downstream about every single
change individually, in particular if I consider the change
unimportant.
To learn about changes upstream, please follow the upstream
discussions, thank you.
This still fails. The expectation here is that downstream consumers know an
upstream change is coming. As evidenced by the various bugs mentioned in
this thread, the result is "surprise, something changed". So the discovery
is reactionary rather than coordinated before putting a change in rawhide.
Hey, there was no need for Fedora to change the path for
/etc/os-release. It was good that it decided to change, but this was
done without contacting me, and I didn't push for it, I was not
involved at all really, and I cannot read people's minds about it. The
change is nothing that would normally considered an "incompatible
change", it just moved one file from /etc to /usr/lib and replaced it
with a symlink.
Please find something else to complain about. THis particular case
makes a really bad example, since I was hardly involved, it wasn't my
side that was communicating badly, but the folks adding this to
Fedora, and that wasn't me.
Are you the owner of systemd or not? You travel the world giving talks
about it, yet when confronted with problems caused by changes in systemd you
point to others and say it's not you. What is it? Either you have a stake
in systemd or not.
Uh? I meant the maintainer of fedora-release.rpm with this.

Sure I have a stake in systemd, but certainly none in
fedora-release.rpm. But even for systemd, there are a number of people
who work on the RPM. And while I feel responsible for it, there will
always be changes made without me knowing, or with me even
agreeing. But it's *good* that way. I trust Zbigniew, and I am not the
control freal who wants to be involved with all choices made... And
quite frankly, I think that Zbigniew is a much nicer guy than I am, so
you should be happy about this.

But anyway, I think it's time to end the discussion, this is
pointless.

In the case of the /etc/resolv.conf change: The change of behaviour in
systemd was simply addition of a fallback code path in case
/etc/resolv.conf was missing. This was communicated to you 6 months
ago. If anaconda/livecd's copy routine would be fixed, then there
would be no issue. This triggered a bug in your package that is
all. No other packages would be affected if this one-line fix was made
to anaconda/livecd.

In the case of the /etc/os-release change: this is actually a minor
change, since compat is provided via a symlink. Adoption by Fedora was
optional, it is great though it happened, and I am thankful that
Zbginiew pushed for it.

Neither issue is an API break, and both changes are rather local and
minor. I am very sure that neither of this changes require grand
theatralic announcements, and in order to keep the noise level low,
there wasn't any. And I'd probably handle the same case the same way
again.

Sorry,

Lennart
--
Lennart Poettering, Red Hat
--
devel mailing list
***@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of
Matthew Miller
2015-02-26 13:29:36 UTC
Permalink
Post by Lennart Poettering
Sure I have a stake in systemd, but certainly none in
fedora-release.rpm. But even for systemd, there are a number of people
Sorry for the somewhat slow reply, but I've been thinking about all of
this.... I guess, primarily, what I'd really hope for is for _all_
Fedora package maintainers to feel like they have a stake in
fedora-release.rpm, at least in a symbolic and general sense. As Fedora
contributors, we should not just think about individual ownership of
the packages we are primarily responsible for, but also how it all fits
together.
--
Matthew Miller
<***@fedoraproject.org>
Fedora Project Leader
--
devel mailing list
***@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-
Jóhann B. Guðmundsson
2015-02-26 14:05:38 UTC
Permalink
Post by Matthew Miller
Post by Lennart Poettering
Sure I have a stake in systemd, but certainly none in
fedora-release.rpm. But even for systemd, there are a number of people
Sorry for the somewhat slow reply, but I've been thinking about all of
this.... I guess, primarily, what I'd really hope for is for _all_
Fedora package maintainers to feel like they have a stake in
fedora-release.rpm, at least in a symbolic and general sense. As Fedora
contributors, we should not just think about individual ownership of
the packages we are primarily responsible for, but also how it all fits
together.
You will need to change the ownership model of packages in the
distribution if you want to change that and related expectations
regarding individual ownership.

Until you do you should expect others to expect relevant maintainer(s)
be responsible for the component they maintain.

JBG
--
devel mailing list
***@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-
Reindl Harald
2015-02-26 14:10:19 UTC
Permalink
Post by Jóhann B. Guðmundsson
Post by Matthew Miller
Post by Lennart Poettering
Sure I have a stake in systemd, but certainly none in
fedora-release.rpm. But even for systemd, there are a number of people
Sorry for the somewhat slow reply, but I've been thinking about all of
this.... I guess, primarily, what I'd really hope for is for _all_
Fedora package maintainers to feel like they have a stake in
fedora-release.rpm, at least in a symbolic and general sense. As Fedora
contributors, we should not just think about individual ownership of
the packages we are primarily responsible for, but also how it all fits
together.
You will need to change the ownership model of packages in the
distribution if you want to change that and related expectations
regarding individual ownership.
Until you do you should expect others to expect relevant maintainer(s)
be responsible for the component they maintain
really?
why?
how do you come to that weird conclusion?

surely, one can say "not my package, not my problem" but that's ignorant
and needs no guidelines and policies - sanity should be enough
Jóhann B. Guðmundsson
2015-02-26 15:37:29 UTC
Permalink
Post by Reindl Harald
really?
why?
how do you come to that weird conclusion?
surely, one can say "not my package, not my problem" but that's
ignorant and needs no guidelines and policies - sanity should be enough
I guess you did not grasp I was referring to the ownership model of
components in the distribution which are irrelevant to guidelines and
policy's.

The fact is the distribution has been using the ownership model since
it's interception which means one to one mapping from a component to an
individual.

As such the thought process of "I take care of what I own has" been
breed into maintainers for the past ten years.

There have been several cases where the community has explode due to
"lack of communications" as an result of that with the most notorious of
those being the Gnome half of the Red Hat's desktop team where more
often than not they have broken bits for other *DE's that have been
sharing underlying components in the distribution. ( search this lists
archives if you need proof of that )

On top of that there are around 15k components in the distribution and
expecting all maintainers to be able to keep tabs on all packager
relations ( to their own or in general ) is ignant or expect them to
does so for a single fedora-release rpm after the distribution has been
split up again into core ( products ) and extra ( the inferior rest )
where the inevitale outcome is for those products eventually start
shipping their own fedora release package...

If the PLL had thought though these thing thoroughly through he would
have realized that.

JBG
--
devel mailing list
***@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduc
Reindl Harald
2015-02-26 15:49:05 UTC
Permalink
Post by Jóhann B. Guðmundsson
Post by Reindl Harald
really?
why?
how do you come to that weird conclusion?
surely, one can say "not my package, not my problem" but that's
ignorant and needs no guidelines and policies - sanity should be enough
I guess you did not grasp I was referring to the ownership model of
components in the distribution which are irrelevant to guidelines and
policy's
i did
Post by Jóhann B. Guðmundsson
The fact is the distribution has been using the ownership model since
it's interception which means one to one mapping from a component to an
individual.
As such the thought process of "I take care of what I own has" been
breed into maintainers for the past ten years.
and i doubt that this is true in general

every maintainer with responsiblity is or should be aware that his piece
is *part of a distribution* because otherwise he could just build his
package outside for his own
Post by Jóhann B. Guðmundsson
There have been several cases where the community has explode due to
"lack of communications" as an result of that with the most notorious of
those being the Gnome half of the Red Hat's desktop team where more
often than not they have broken bits for other *DE's that have been
sharing underlying components in the distribution. ( search this lists
archives if you need proof of that )
and without the "ownership model" it would have been prevented
what model would you use?
you can't only say "that model is wrong" without any alternative

having everybody mangle every package is also not a solution because you
can't expect the needed knowledge for mangle around in a perl package
from a java-user and so on
Post by Jóhann B. Guðmundsson
On top of that there are around 15k components in the distribution and
expecting all maintainers to be able to keep tabs on all packager
relations ( to their own or in general ) is ignant or expect them to
does so for a single fedora-release rpm after the distribution has been
split up again into core ( products ) and extra ( the inferior rest )
where the inevitale outcome is for those products eventually start
shipping their own fedora release package...
If the PLL had thought though these thing thoroughly through he would
have realized that.
that's a completly different topic
Jóhann B. Guðmundsson
2015-02-26 15:54:46 UTC
Permalink
Post by Reindl Harald
and without the "ownership model" it would have been prevented
what model would you use?
you can't only say "that model is wrong" without any alternative
I have already mentioned alternative before no need to repeat that
proposal to you.

Bottom line that model will not be change due to Red Hat requiring to
keep components it ships under its own control.

Why do you think the distribution has been split into cores and extra
again now through "products" ?

JBG
--
devel mailing list
***@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/c
Reindl Harald
2015-02-26 15:58:09 UTC
Permalink
Post by Jóhann B. Guðmundsson
Post by Reindl Harald
and without the "ownership model" it would have been prevented
what model would you use?
you can't only say "that model is wrong" without any alternative
I have already mentioned alternative before no need to repeat that
proposal to you.
Bottom line that model will not be change due to Red Hat requiring to
keep components it ships under its own control.
you typical Red Hat flame.....
Post by Jóhann B. Guðmundsson
Why do you think the distribution has been split into cores and extra
again now through "products"?
that is nonsense and you know that!
Jóhann B. Guðmundsson
2015-02-26 16:03:31 UTC
Permalink
Post by Reindl Harald
Post by Jóhann B. Guðmundsson
Post by Reindl Harald
and without the "ownership model" it would have been prevented
what model would you use?
you can't only say "that model is wrong" without any alternative
I have already mentioned alternative before no need to repeat that
proposal to you.
Bottom line that model will not be change due to Red Hat requiring to
keep components it ships under its own control.
you typical Red Hat flame.....
s/flame/facts
Post by Reindl Harald
Post by Jóhann B. Guðmundsson
Why do you think the distribution has been split into cores and extra
again now through "products"?
that is nonsense and you know that!
It is not.

JBG
--
devel mailing list
***@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproj
Miloslav Trmač
2015-02-23 18:44:01 UTC
Permalink
Post by Lennart Poettering
Communication is a two way street, and as an upstream I cannot be in
the business of pinging every single downstream about every single
change individually, in particular if I consider the change
unimportant.
Sure, that makes sense.
Post by Lennart Poettering
To learn about changes upstream, please follow the upstream
discussions, thank you.
However, this isn’t practical. The 1619! members of the packager group can’t be following every single upstream mailing list of every single project they depend on or they may be affected by. That is why we have http://fedoraproject.org/wiki/Package_maintainer_responsibilities#Notify_others_of_changes_that_may_affect_their_packages , and why we _need_ that policy; it is not a gratuitous bureaucratic nonsense.

Both systemd and Fedora would benefit if this communication were factored out like this, by having a Fedora liaison/“watcher” of systemd¹ that is primarily concerned with needs of Fedora and impact on Fedora.
Mirek

¹ The Package maintainer responsibilities document places this on the package maintainers; but this would work equally well if anyone else did this, with or without commit rights to the systemd RPM.
--
devel mailing list
***@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: ht
Zbigniew Jędrzejewski-Szmek
2015-02-23 15:35:39 UTC
Permalink
Post by Dennis Gilmore
On Fri, 20 Feb 2015 17:36:17 +0100
Post by Lennart Poettering
Post by Peter Robinson
Post by Lennart Poettering
Post by Harald Hoyer
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.
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?
A recent example, systemd decided that os-release needed to be moved
to /usr/lib/
Rahul Sundaram and I asked for this change to follow upstream and because
it is a step in the right direction and we might just as well make it now.
A symlink is both carried by fedora-release.rpm and added automatically by
systemd if the file is missing, so most consumers should not be affected.

I don't agree with Lennart here there we should delay changes which
incrementally move us towards the goal of empty /etc. It's not that
far out and with every file moved it becomes easier. We should be
changing the mindset of what belong in /etc, and os-release is part
of the basic file system and has symbolic importance.
Post by Dennis Gilmore
contacted directly. the first I heard of it was a third party person
filing a bug against fedora-release
It turns out that dracut was affected, but the bug is easy enough to
fix. If fedora-devel was used to announce every file move we'd all
go crazy.

And seriously, Rahul Sundaram is hardly a "third party person". He's one
of the active maintainers of systemd package, which you can easily
check in the pkgdb, as well as your colleague from Red Hat.
But even if he was, it should hardly matter. He made a bug report
providing the necessary justification (quoting upstream manpage), and
it should make no difference whether he is active in other areas
or if that bug report was his first contribution to Fedora.

Zbyszek
--
devel mailing list
***@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Condu
Rahul Sundaram
2015-02-23 15:54:06 UTC
Permalink
Hi
Post by Zbigniew Jędrzejewski-Szmek
And seriously, Rahul Sundaram is hardly a "third party person". He's one
of the active maintainers of systemd package, which you can easily
check in the pkgdb, as well as your colleague from Red Hat.
Neither is correct at this point but as you note below, this isn't the
relevant part

But even if he was, it should hardly matter. He made a bug report
Post by Zbigniew Jędrzejewski-Szmek
providing the necessary justification (quoting upstream manpage), and
it should make no difference whether he is active in other areas
or if that bug report was his first contribution to Fedora.
FWIW, just in case anyone is curious, I filed a bug report against Google
Chrome to drop the dependency on redhat-lsb package since it is a meta
package for a while and pulls in a long list of dependencies and the only
reason afaik for this dependency is to read the distribution name and
version. os-release provides a standard location and format for this
information these days but it is confusing to have the system behave
differently from how the documentation says it should be setup and I
requested the change and it has been subsequently made (not by me).

I also independently filed a bug report to deprecate the distro specific
file but FESCo has rejected that. I don't believe that having this
information in multiple places is a good way to maintain a distribution and
we should strive to move to a single canonical location. I don't see a
reason not to add some documentation providing an advance notice of this
but whatever.

Rahul
Nico Kadel-Garcia
2015-02-23 13:45:56 UTC
Permalink
On Fri, Feb 20, 2015 at 11:36 AM, Lennart Poettering
Post by Lennart Poettering
Post by Peter Robinson
Post by Lennart Poettering
Post by Peter Robinson
Post by Harald Hoyer
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.
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?
Post by Peter Robinson
Post by Lennart Poettering
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."
Post by Lennart Poettering
Post by Peter Robinson
Post by Lennart Poettering
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?
Post by Lennart Poettering
Anyway, I have the suspicion you just want to make a fuss, and this is
where it ends for me hence.
And this is the other reason people don't trust your project. Systemd
feature growth has been pretty pedal to the metal. Even if the new
model is *better* in terms of your or your group's network
configuration paradigms, it requires breaking long stable workflows
and configurations.
--
devel mailing list
***@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora
Pierre-Yves Chibon
2015-02-23 14:01:47 UTC
Permalink
Post by Nico Kadel-Garcia
On Fri, Feb 20, 2015 at 11:36 AM, Lennart Poettering
Post by Lennart Poettering
Post by Peter Robinson
Post by Lennart Poettering
Post by Peter Robinson
Post by Harald Hoyer
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.
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?
Post by Peter Robinson
Post by Lennart Poettering
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.
Post by Nico Kadel-Garcia
Post by Lennart Poettering
Post by Peter Robinson
Post by Lennart Poettering
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
***@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of
Lennart Poettering
2015-02-23 15:43:25 UTC
Permalink
Post by Nico Kadel-Garcia
Post by Lennart Poettering
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.
You know, that systemd creates a symlink if the file is missing is not
going to change behaviour of anything, since it will only do something
if the file is *missing*. And it won#t be missing if anaconda copies
in its stuff as it currently does. I mean, the issue is really about
this copy routine being broken, and not about systemd having a
fallback logic to create /etc/resolv.conf if it is missing.

If anaconda's file copy routine would not be confused by symlinks in
the destination, the issue goes away entirely: it would create its
file, and systemd's /etc/resolv.conf logic would never touch anything
anymore.
Post by Nico Kadel-Garcia
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?
No, they don't. Only anaconda has, since it starts with an empty /etc.

That said, I think it would be a ton better if those frameworks you
list would be able to deal with /etc/resolv.conf being a symlink.
Post by Nico Kadel-Garcia
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."
Note that this would matter here at all /etc/resolv.conf being a
symlink is hardly a new concept. See Debian's "resolvconf" package for
example...
Post by Nico Kadel-Garcia
Post by Lennart Poettering
Post by Peter Robinson
Post by Lennart Poettering
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.
Hey, if you want to know what's going on in systemd development, then
pelase join our upstream mailing list.

And no, I will not forward all systemd design discussions to the
fedora ML, it has no place there. We don't forward them to the suse,
debian, ubuntu MLs either.
Post by Nico Kadel-Garcia
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?
Nope. All that systemd does is create it as symlinks if it is
otherwise missing. If you put something else there, then that's what
counts.

Lennart
--
Lennart Poettering, Red Hat
--
devel mailing list
***@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.or
Andrew Lutomirski
2015-02-23 15:56:50 UTC
Permalink
On Mon, Feb 23, 2015 at 7:43 AM, Lennart Poettering
Post by Lennart Poettering
Post by Nico Kadel-Garcia
Post by Lennart Poettering
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.
You know, that systemd creates a symlink if the file is missing is not
going to change behaviour of anything, since it will only do something
if the file is *missing*. And it won#t be missing if anaconda copies
in its stuff as it currently does. I mean, the issue is really about
this copy routine being broken, and not about systemd having a
fallback logic to create /etc/resolv.conf if it is missing.
If anaconda's file copy routine would not be confused by symlinks in
the destination, the issue goes away entirely: it would create its
file, and systemd's /etc/resolv.conf logic would never touch anything
anymore.
As a bystander, I'm lost here.

Systemd made a change. I'm not sure what the change is.

Anaconda is supposedly confused by destination/etc/resolv.conf being a
symlink. What is anaconda *supposed* to do? Options seem to include:

1. Do nothing.
2. Delete the symlink and replace it.
3. Follow the symlink, delete the target, and replace it.
4. Follow the symlink and overwrite the target.

Knowing little about what systemd is doing here, I would argue for
(1). If it's a symlink, then presumably something manages whatever
the symlink points to.

OTOH, this is *anaconda* we're talking about. Maybe it should do
whatever it needs to do to make the installed Fedora system happy,
whatever that is.

--Andy
--
devel mailing list
***@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: h
Zbigniew Jędrzejewski-Szmek
2015-02-23 19:18:46 UTC
Permalink
Post by Andrew Lutomirski
On Mon, Feb 23, 2015 at 7:43 AM, Lennart Poettering
Post by Lennart Poettering
Post by Nico Kadel-Garcia
Post by Lennart Poettering
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.
You know, that systemd creates a symlink if the file is missing is not
going to change behaviour of anything, since it will only do something
if the file is *missing*. And it won#t be missing if anaconda copies
in its stuff as it currently does. I mean, the issue is really about
this copy routine being broken, and not about systemd having a
fallback logic to create /etc/resolv.conf if it is missing.
If anaconda's file copy routine would not be confused by symlinks in
the destination, the issue goes away entirely: it would create its
file, and systemd's /etc/resolv.conf logic would never touch anything
anymore.
As a bystander, I'm lost here.
Systemd made a change. I'm not sure what the change is.
Previously all sources which could provide a list of dns server would
fight over /etc/resolv.conf. This includes: explicit configuration by
the admin, dhcplient, NetworkManager, systemd-resolved, local dns servers.

Additional issue is that the list of dns servers is inherently
dynamic, which conflicts with read-only root filesystem.

The change: various provides of resolv.conf contents create files in
temporary storage (under /run), and the administrator symlinks to the
one he or she wants to be used.
Post by Andrew Lutomirski
Anaconda is supposedly confused by destination/etc/resolv.conf being a
1. Do nothing.
2. Delete the symlink and replace it.
3. Follow the symlink, delete the target, and replace it.
4. Follow the symlink and overwrite the target.
Anaconda should do 2. It can either provide a static file, or it can
replace the symlink with a symlink of its own choosing. For example,
it could symlink to the resolv.conf file provided by NetworkManager if
NetworkManager is being installed in the system.

It shouldn't do 1., because that would result in broken network, and
it shouldn't do 3 or 4 because the target of the symlink is
systemd-resolved territory.
Post by Andrew Lutomirski
Knowing little about what systemd is doing here, I would argue for
(1). If it's a symlink, then presumably something manages whatever
the symlink points to.
OTOH, this is *anaconda* we're talking about. Maybe it should do
whatever it needs to do to make the installed Fedora system happy,
whatever that is.
Yes, anaconda is installing the system, and knows how the network is
supposed to set up. It should set /etc/resolv.conf accordingly.

Zbyszek
--
devel mailing list
***@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Co
Colin Walters
2015-02-23 21:02:50 UTC
Permalink
There are patches waiting in: https://bugzilla.redhat.com/show_bug.cgi?id=1116651

And I think almost every poster so far in this thread has the technical knowledge to review them.
--
devel mailing list
***@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code
Zbigniew Jędrzejewski-Szmek
2015-02-24 00:51:17 UTC
Permalink
Post by Colin Walters
There are patches waiting in: https://bugzilla.redhat.com/show_bug.cgi?id=1116651
And I think almost every poster so far in this thread has the technical knowledge to review them.
Yeah, sorry, I previously looked at the anaconda patch, and they only thing
that looked bad was 'except OSError, e' (i.e. python 2.5 syntax). Looking
at it again, it might be better to warn and continue if the removal fails.
Missing resolv conf is probably not worth breaking installation over.
The same applies for the other patch.

Zbyszek
Post by Colin Walters
--
devel mailing list
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
--
devel mailing list
***@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: htt
Orion Poplawski
2015-02-24 02:06:00 UTC
Permalink
Post by Zbigniew Jędrzejewski-Szmek
Post by Colin Walters
There are patches waiting in: https://bugzilla.redhat.com/show_bug.cgi?id=1116651
And I think almost every poster so far in this thread has the technical knowledge to review them.
Yeah, sorry, I previously looked at the anaconda patch, and they only thing
that looked bad was 'except OSError, e' (i.e. python 2.5 syntax). Looking
at it again, it might be better to warn and continue if the removal fails.
Missing resolv conf is probably not worth breaking installation over.
The same applies for the other patch.
Zbyszek
If this somehow ended up fixing
https://bugzilla.redhat.com/show_bug.cgi?id=874806 by making
/etc/resolv.conf available before authconfig was run, that would be an
added bonus.
--
Orion Poplawski
Technical Manager 303-415-9701 x222
NWRA/CoRA Division FAX: 303-415-9702
3380 Mitchell Lane ***@cora.nwra.com
Boulder, CO 80301 http://www.cora.nwra.com
--
devel mailing list
***@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/co
Nico Kadel-Garcia
2015-02-27 13:18:12 UTC
Permalink
On Mon, Feb 23, 2015 at 10:43 AM, Lennart Poettering
[ notes snipped, ]
Post by Lennart Poettering
You know, that systemd creates a symlink if the file is missing is not
going to change behaviour of anything, since it will only do something
if the file is *missing*.
Congratulations. We now have inconsistent behavior if anyone, *ever*,
edits /etc/resolf.conf with 'sed -i', uses "rsync -a" or "cp -a" tp
reproduce it from a known good repository, and with a symlink in place
we're storing absolutely critical system information in a non /etc
location, meaning that non-modified backup systems won't get a copy
with valid content.

Just..... great.

Look, deciding to ignore the File System Hierarchy for installing
config files and creating new locations to store system configuration
is part of what killed the old "daemontools" init system replacement.
tool. You and the other developers have gone well past that. But these
are not tiny surprises, and the anaconda team is far, far, far from
the only people who need a heads up on structural surprises like this.
Post by Lennart Poettering
Hey, if you want to know what's going on in systemd development, then
pelase join our upstream mailing list.
You probably wouldn't like it. I'd scream about things like this. The
time I can spare for this is spent cleaning up the mess when systemd
based tools from Fedora are unusable under RHEL 5 or 6 without folks
like me putting in hooks to detect and handle real init scripts, and
vice versa. It's over hat https://github.com/nkadel/.
Post by Lennart Poettering
And no, I will not forward all systemd design discussions to the
fedora ML, it has no place there. We don't forward them to the suse,
debian, ubuntu MLs either.
This wasn't merely a "discussion", it was an unexpected behavioral
change in a vital system configuration file.
Post by Lennart Poettering
Post by Nico Kadel-Garcia
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?
Nope. All that systemd does is create it as symlinks if it is
otherwise missing. If you put something else there, then that's what
counts.
And you've introduced a permanent inconsistency between systems that
were ever touched by an admin or a tool aware of symlinks, and one
that has not been so touched. And introduced a backup configuration
issue: network configuration backups, or even source control systems
that store /etc/resolv.conf, all need to be tweaked.

These are not the largest of issues, but they're very real.
Personally? I'd say "either always use a symlink, or never use one".
Please do not try to deduce the sys-admin's intent from which editing
tool they happen to use and its secondary behavior. The handling of
symlinks can seriously, seriously bite you at odd moments.

This is also not a new problem: this is not the first time that
out-of-band information got stuck someplace weird and took extra work
and knowledge to deal with. When tools like "system-config-network"
started hiding content in /etc/sysconfig/networking/profiles and
/etc/sysconfig/networking/devices, some of us had to learn about
scrubbing those away or making them consistent in order to make sure
that /etc/sysconfig/network-scripts/ifcfg-* changes got propagated
reliably in Fedora and RHEL systems. But it's a *surprise* when it
happens, and it's extra work in day to day network administration.

And yeah, it happened Monday dealing with virtualized OS image given a
new MAC address and with old MAC address embedded in weird places.
--
devel mailing list
***@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject
Nico Kadel-Garcia
2015-02-27 13:25:36 UTC
Permalink
Post by Nico Kadel-Garcia
Look, deciding to ignore the File System Hierarchy for installing
config files and creating new locations to store system configuration
is part of what killed the old "daemontools" init system replacement.
tool. You and the other developers have gone well past that. But these
are not tiny surprises, and the anaconda team is far, far, far from
the only people who need a heads up on structural surprises like this.
I seem to be having trouble with my positive and negative parity this morning.

I meant that they've gone well past the stage of acceptance and
deployment that daemontools ever reached, so it's unlikely to be
effectively abandoned as daemontools has been. I'll restrain my
technical comparisons.
Post by Nico Kadel-Garcia
And you've introduced a permanent inconsistency between systems that
were ever touched by an admin or a tool aware of symlinks, and one
that has not been so touched. And introduced a backup configuration
issue: network configuration backups, or even source control systems
that store /etc/resolv.conf, all need to be tweaked.
See above. I meant an admin *unaware* of symlinks.
--
devel mailing list
***@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code
Jóhann B. Guðmundsson
2015-02-27 14:48:01 UTC
Permalink
Post by Nico Kadel-Garcia
On Mon, Feb 23, 2015 at 10:43 AM, Lennart Poettering
[ notes snipped, ]
Post by Lennart Poettering
You know, that systemd creates a symlink if the file is missing is not
going to change behaviour of anything, since it will only do something
if the file is*missing*.
Congratulations. We now have inconsistent behavior if anyone,*ever*,
edits /etc/resolf.conf with 'sed -i', uses "rsync -a" or "cp -a" tp
reproduce it from a known good repository, and with a symlink in place
we're storing absolutely critical system information in a non /etc
location, meaning that non-modified backup systems won't get a copy
with valid content.
Just..... great.
I guess you missed the part that it did nothing if the file existed.

Even after spending what 8 years in Fedora's QA ( longer than any of
their so called hired employee working in that area ) as well as
handling the systemd integration for wide variety of component I was not
even allowed to see RHEL systemd integration bug trackers until in some
case other Red Hat employees ranted over their coworkers how stupid they
were not allowing the guy handling the integration doing so.

I know first hand the state of systemd in Fedora and I have seen the
state it's in RHEL and I know Red Hat did nothing to improve the
situation from what it was in Fedora not even make some of those
implementations "enterprise grade" so regarding the rest of your rant
neither upstream nor Fedora ( despite Red Hat royally abusing it's
community and shape it in it's image ) has any control over any
decisions Red Hat makes about it's RHEL release so use that support
contract you are paying Red Hat for and wreak havoc with them.

Hopefully that havoc from you and from other customers will ring some
wakeup bells with it's managers and get them thinking.

JBG
Zbigniew Jędrzejewski-Szmek
2015-02-27 15:21:51 UTC
Permalink
Post by Nico Kadel-Garcia
On Mon, Feb 23, 2015 at 10:43 AM, Lennart Poettering
[ notes snipped, ]
Post by Lennart Poettering
You know, that systemd creates a symlink if the file is missing is not
going to change behaviour of anything, since it will only do something
if the file is *missing*.
Congratulations. We now have inconsistent behavior if anyone, *ever*,
edits /etc/resolf.conf with 'sed -i', uses "rsync -a" or "cp -a" tp
reproduce it from a known good repository, and with a symlink in place
we're storing absolutely critical system information in a non /etc
location, meaning that non-modified backup systems won't get a copy
with valid content.
Just..... great.
Look, deciding to ignore the File System Hierarchy for installing
config files and creating new locations to store system configuration
Actually it might be considered that we are *starting* to follow FHS.
In many (most?) setups /etc/resolv.conf configuration is very dynamic:
the set of resolvers depends on dhcp leases, VPNs, network interfaces
coming and going. Storing this information in /etc/ is wrong. It's good
that this ephmeral content is not backed up. If the machine reboots, you
do not want to restore it, you want to recreate it from scratch.

If someone has a static setup and a static resolv.conf is fine for them,
there's no problem: just create a normal file.

OK, this change is not transparent to tools that write resolver
information. The new scheme requires some changes, but it's not more
complicated than the old scheme. It is actually easier for the admin,
because it gives full control over the symlink to them, and easier for
the tools, because they don't have to fight over the contents of the
file.
Post by Nico Kadel-Garcia
Post by Lennart Poettering
Hey, if you want to know what's going on in systemd development, then
pelase join our upstream mailing list.
I know that this is not realistic. But it's not really necessary. This
issue discussed before F21, and an number of Anaconda people
participated in the discussion. The bug was open for the last 6 months.
Post by Nico Kadel-Garcia
Post by Lennart Poettering
Post by Nico Kadel-Garcia
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?
Nope. All that systemd does is create it as symlinks if it is
otherwise missing. If you put something else there, then that's what
counts.
The file that is written by systemd-resolved contains the following header:

# This file is managed by systemd-resolved(8). Do not edit.
#
# Third party programs must not access this file directly, but
# only through the symlink at /etc/resolv.conf. To manage
# resolv.conf(5) in a different way, replace the symlink by a
# static file or a different symlink.

I'll try to tweak this text a bit to be clearer on the symlink issue.
I don't have a NetworkManager generated file at hand to see, but it
should probably carry something similar.
Post by Nico Kadel-Garcia
Personally? I'd say "either always use a symlink, or never use one".
Please do not try to deduce the sys-admin's intent from which editing
tool they happen to use and its secondary behavior. The handling of
symlinks can seriously, seriously bite you at odd moments.
We need the file to be a symlink for some usecases.
We *could* deprecate /etc/resolv.conf as a normal file, and always
create it as a symlink. Anaconda would then write (say) /etc/resolv.conf.static,
and symlink /etc/resolv.conf → resolv.conf.static. This is really beyond
systemd, since systemd does not create the static file ever.

Zbyszek
--
devel mailing list
***@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http
Brian C. Lane
2015-03-02 16:42:25 UTC
Permalink
Post by Zbigniew Jędrzejewski-Szmek
Post by Nico Kadel-Garcia
On Mon, Feb 23, 2015 at 10:43 AM, Lennart Poettering
[ notes snipped, ]
Post by Lennart Poettering
You know, that systemd creates a symlink if the file is missing is not
going to change behaviour of anything, since it will only do something
if the file is *missing*.
Congratulations. We now have inconsistent behavior if anyone, *ever*,
edits /etc/resolf.conf with 'sed -i', uses "rsync -a" or "cp -a" tp
reproduce it from a known good repository, and with a symlink in place
we're storing absolutely critical system information in a non /etc
location, meaning that non-modified backup systems won't get a copy
with valid content.
Just..... great.
Look, deciding to ignore the File System Hierarchy for installing
config files and creating new locations to store system configuration
Actually it might be considered that we are *starting* to follow FHS.
the set of resolvers depends on dhcp leases, VPNs, network interfaces
coming and going. Storing this information in /etc/ is wrong. It's good
that this ephmeral content is not backed up. If the machine reboots, you
do not want to restore it, you want to recreate it from scratch.
If someone has a static setup and a static resolv.conf is fine for them,
there's no problem: just create a normal file.
The underlying problem here is that it isn't just created when it is
missing. It is created *before* other tools have a chance to create it.
As I explained in 1197204 the boot.iso is created without a
/etc/resolv.conf, this means that NM should create it with whatever
content it needs. Except that systemd-tmpfiles comes along first,
assumes it can create it and then breaks NM.

Upstream has declined to fix this, so we're going to need the patch
that's been applied to f21 and f22 carried forward until that changes.
--
Brian C. Lane | Anaconda Team | IRC: bcl #anaconda | Port Orchard, WA (PST8PDT)
--
devel mailing list
***@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduc
Dan Williams
2015-03-02 17:43:27 UTC
Permalink
Post by Brian C. Lane
Post by Zbigniew Jędrzejewski-Szmek
Post by Nico Kadel-Garcia
On Mon, Feb 23, 2015 at 10:43 AM, Lennart Poettering
[ notes snipped, ]
Post by Lennart Poettering
You know, that systemd creates a symlink if the file is missing is not
going to change behaviour of anything, since it will only do something
if the file is *missing*.
Congratulations. We now have inconsistent behavior if anyone, *ever*,
edits /etc/resolf.conf with 'sed -i', uses "rsync -a" or "cp -a" tp
reproduce it from a known good repository, and with a symlink in place
we're storing absolutely critical system information in a non /etc
location, meaning that non-modified backup systems won't get a copy
with valid content.
Just..... great.
Look, deciding to ignore the File System Hierarchy for installing
config files and creating new locations to store system configuration
Actually it might be considered that we are *starting* to follow FHS.
the set of resolvers depends on dhcp leases, VPNs, network interfaces
coming and going. Storing this information in /etc/ is wrong. It's good
that this ephmeral content is not backed up. If the machine reboots, you
do not want to restore it, you want to recreate it from scratch.
If someone has a static setup and a static resolv.conf is fine for them,
there's no problem: just create a normal file.
The underlying problem here is that it isn't just created when it is
missing. It is created *before* other tools have a chance to create it.
As I explained in 1197204 the boot.iso is created without a
/etc/resolv.conf, this means that NM should create it with whatever
content it needs. Except that systemd-tmpfiles comes along first,
assumes it can create it and then breaks NM.
With NM <= 1.0, it will create a tempfile in /etc and then rename that
over top of the existing /etc/resolv.conf, though it does try to follow
a link (with realpath(2)) and replace that file atomically (with
rename(2)). If that's being broken by systemd we should probably handle
this case better in NM too, along with whatever systemd changes need to
happen.

With NM > 1.0, NM will stop touching resolv.conf at all if it's a
symlink, because that file is owned by some other process. NM will
still write out it's own resolv.conf to /var/run. If resolv.conf is a
file, and NM is allowed to manage DNS through its config, then NM will
make resolv.conf a symlink to its file in /var/run, much like I
understand systemd does.

Dan
--
devel mailing list
***@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-condu
Kevin Fenzi
2015-03-02 17:49:53 UTC
Permalink
On Mon, 2 Mar 2015 08:42:25 -0800
Post by Brian C. Lane
The underlying problem here is that it isn't just created when it is
missing. It is created *before* other tools have a chance to create
it. As I explained in 1197204 the boot.iso is created without a
/etc/resolv.conf, this means that NM should create it with whatever
content it needs. Except that systemd-tmpfiles comes along first,
assumes it can create it and then breaks NM.
Perhaps the tmpfiles entry for /etc/resolv.conf should be moved to a
systemd-networkd tmpfile entry? Then, if you do not install that it's
assumed NM or whatever will create the entry, if you do, it can then
manage that file that gets created.
Post by Brian C. Lane
Upstream has declined to fix this, so we're going to need the patch
that's been applied to f21 and f22 carried forward until that changes.
Is there an upstream bug or discussion we can look at?

Yeah, I was hoping to get a nice rawhide Xfce 4.12 image to test with
today, but of course it hit this bug and didn't get created. ;(

kevin

Rahul Sundaram
2015-02-20 16:42:25 UTC
Permalink
Hi
Post by Lennart Poettering
How many months would you like me to notify people in advance of a
simple change like this? Isn't 6 month *ample* time?
The problem isn't necessarily the speed of change but the amount of
caution and attention paid to inform folks affected by such changes. It is
a fairly simple change in this case but it affects more than just one
component and not everyone is aware of the details in the first place. A
simple announcement here or fedora devel announce list would go a long way.

Rahul
Florian Weimer
2015-02-20 16:43:05 UTC
Permalink
Post by Lennart Poettering
Also, NM fixed a similar issue with /etc/resolve.conf in their code a
long time ago, to my knowledge. Am I so misguided to assume that
Anaconda can fix a fricking file copy too, in all those months?
Maybe it is time to step back and consider if replacing /etc/resolv.conf
with a symbolic link is something that can be reasonably implemented
from a backwards compatibility perspective?

Usually, if we face this much trouble within Fedora itself, it's a good
indicator of the pain that we'll have to deal with downstream.
--
Florian Weimer / Red Hat Product Security
--
devel mailing list
***@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora
Dan Williams
2015-02-20 17:02:37 UTC
Permalink
Post by Florian Weimer
Post by Lennart Poettering
Also, NM fixed a similar issue with /etc/resolve.conf in their code a
long time ago, to my knowledge. Am I so misguided to assume that
Anaconda can fix a fricking file copy too, in all those months?
Maybe it is time to step back and consider if replacing /etc/resolv.conf
with a symbolic link is something that can be reasonably implemented
from a backwards compatibility perspective?
Usually, if we face this much trouble within Fedora itself, it's a good
indicator of the pain that we'll have to deal with downstream.
I would love to know the outcome of this discussion, since we just made
a change to NetworkManager git master (will be version 1.2, target
Fedora 23) to make /etc/resolv.conf a symlink when it's under NM's
control. If there are problems here, we want to know too.

* NM won't replace a symlinked /etc/resolv.conf that doesn't point to
NM's copy in /var
* You can disable this behavior with "dns=none"
in /etc/NetworkManager/NetworkManager.conf and manage resolv.conf on
your own too

Dan
--
devel mailing list
***@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/cod
Loading...