implementation recommendation

Change History

Reverting this gives us almost nothing. Any change to hostname, locale from the desktop will create
the new files, which effectively disable the old files. The same happens when anaconda runs.

As you can see, the above mentioned change triggers only in the case the new files do not exist, which
only happens if no recent anaconda never ran before on the installed system, and the user never used
any of the desktop tools. Reverting this will effectively not make any real difference.

We should focus on fixing the remaining issues, if there are ones, and not try to pretend all would
work with the status quo. These files are almost entirely dead to the system, they are not read if the
new files exist, they are just confusing text without much effect; hence we better remove it when
we detect a clear state of a transition from old to new.

Sure, there are things missing and to fix, like always, but reverting does not bring us any closer
to where we need to be. Now, I would think, that removing the "does the new file exist" check and
do all that unconditionally would even be the better move than reverting, sticking the head in
the sand, and hope all will work.

In any case, moving data from documented files without any user notification, not even a release note, is really bad form.

As detailed below, moving the information breaks other applications; without any reason to think otherwise, "the desktop tools" that move the information are therefore buggy / badly integrated with the rest of the distribution and should have been fixed to integrate better in the first place, instead of now using them as an argument that the rest needs to adapt.

The same happens when anaconda runs.

As you can see, the above mentioned change triggers only in the case the new files do not exist, which
only happens if no recent anaconda never ran before on the installed system, and the user never used
any of the desktop tools. Reverting this will effectively not make any real difference.

On upgrades, anaconda doesn't run in the traditional sense any more.

These kinds of data are typically set during installation and never modified by a GUI. I'd expect any use of "the desktop tools" to be rarer than using any configuration management system to manage the old file, which is broken by the change.

And from the developer point of view:

Sure, there are things missing and to fix, like always,

"There are things missing, like always" is not the quality standard I want to see from a core system component. How can I rely on a base like that?

We do have other software that use the existing files and not the new ones. system-config-language is a very obvious case.

but reverting does not bring us any closer
to where we need to be.

(I can't see any great "need" here, but that's a side issue.) Wherever you want to go, breaking things without any notification to affected developers, and on the day of a freeze, which makes it close to impossible for the affected developers to catch up even if they noticed, is just not a way the 1279 Fedora packagers can collaborate on this distribution.

Moving the files should be a full feature, with the associated notification, documentation and testing requirements.

Don't get me wrong, I don't disagree much here, at least not with the theory behind it.

But most of the issues are already in F16+F17 and this change does not make it worse. We need
to fix stuff for good. Believe me, we will not fix anything by reverting *this* change, it is
just not the problem. It would be just ignoring the reality, not help with anything we need
to do.

People just pointed out the, if you look at it from outside, obvious inconsistency with the
duplicated files, which are not even read anymore, so we just went ahead and fully converted
the old one to the new ones, if there is a clear detectable state.

We have delayed this problem for too long, and the above mentioned commit does not make it worse,
it's just a very tiny piece in the puzzle. So, yeah, stuff is sub-optimal an inconsistent for
a full year now, we just did not realize it. It goes back as far as F16, and that's where we
probably missed the *feature* to do that, if we did.

Reverting *this* change will not help with anything. We need to find out what to do
instead, and not pretend all was working before that change, it wasn't at all. So let's come
up with a plan please, and leave the politics, rules, and formalities behind, it's too late
we already missed that opportunity looong ago, and applying them now is just theater and
pretty useless for users and developers.

In short: tell me to revert it, I'll just do it right away to stop this game here, but you have
absolutely nothing accomplished by that, besides wasted our time; the system will carry out at
least the same inconsistency as it had before.

I agree with Marcela, this step should be pushed to rawhide. Doing such a change just a few hours before freeze should be avoided, as it's just unnecessary. That's what rawhide is for.
Also, at first glance, this change seems to be done without a real reason (I hope, I'm wrong). Doing such a step without a public notice on fedora development list is just unfriendly.

Having it documented "somewhere" makes it even ubuntu style ("The user/upstream is free to pick relevant pieces of information from launchpad"). I expect Fedora to be different from that.

There are still concerns about stability of Fedora. We have so many rules on updates into Fedora, that no-one understand them, but when bigger change before freeze arise everyone is happy about that.

As I stated in a thread I'm not sure how much damage will be done, but we shouldn't ack such changes in the last minute. It's unfair to other people who fill their feature pages and warn others about possible breakage.

F18 before change, update: old files exist; tools using /etc/sysconfig/i18n work unless and until tools using /etc/locale.conf are used; tools using /etc/locale.conf work.

F18 after change, update: old files exist and are migrated; tools using /etc/sysconfig/i18n don't work; tools using /etc/locale.conf work.

So the decision is between breaking tools on upgrade to F18, and consistency of behavior in F18. Or we could extend this to revert both systemd and anaconda, and keep the F<=17 behavior for all F18 cases.

As much as I hate to say it, I prefer consistency of behavior in F18, and not invalidating anaconda testing, i.e. keeping F18 as it is. (Thanks to Johann and Peter to taking care of the release note.)

And the reason I hate to say it:

So let's come
up with a plan please, and leave the politics, rules, and formalities behind, it's too late
we already missed that opportunity looong ago,

The "politics, rules and formalities" are how the 1200 developers coordinate. Ignoring them rewards the uncooperative behavior.

(The decision of what to do in F18 remains up to FESCo on the next meeting; considering that nobody is proposing to block it forever, and supporting the systemd files would be an improvement even on older releases, AFAICS the bugs can be filed now.)

obvious other candidates to check are the KDE and GNOME control center applets, which can do stuff to clocks, language and keyboard settings. we have system-config-date and system-config-keyboard that are Fedora specific. I believe system-config-date is already being worked on and there is an update for testing at present. I'm not sure if Xfce has applets for configuring any of this, but it may.

obvious other candidates to check are the KDE and GNOME control center applets, which can do stuff to clocks, language and keyboard settings. we have system-config-date and system-config-keyboard that are Fedora specific. I believe system-config-date is already being worked on and there is an update for testing at present. I'm not sure if Xfce has applets for configuring any of this, but it may.

At least GNOME uses systemd's timedated mechanism anyway, so will do the right thing anyway. Not sure about KDE.

Kay, we are waiting for your reply. I do not have any idea how to find out, which packages might be broken by your change. But you was working on the change, so you have probably more information about the area. I'd like to see list of packages, which are using old config files and fixes for them.

In the FESCo meeting on 2012-10-31 the availability of a machine with an exploded Fedora source tree was mentioned. Kay and I tried to get information on how to access it. mjg59 told us it's ihatethathostname.lab.bos.redhat.com. He said he'd found out who can grant us access to it. I understand he's been busy, so we haven't received this information yet. If anyone else knows, please tell us.

If it turns out firstboot is always using en_US.UTF8 instead of the users install language, we will fix that one and get it added as a blocker. Other packages can fix this now in rawhide or as a post release update.