Bug 999114

Best component for this is rootfiles, filesystem shouldn't handle files. Rootfiles component is kept to be as close as possible to the default /etc/skel content with few exceptions. If you have any comment/idea what should be improved there, feel free to propose it.

Should not the component that creates the root user in the first place be responsible for creating root's home directory and copy the contents of /etc/skel into it?

I don't think so - root's home directory is part of FHS, so it is created by filesystem package. Package rootfiles adds the files into it. Basic system accounts should be created by setup package, but I don't think this should handle the root's home directory content and copy /etc/skel content.

First of all, common files from /etc/skel are owned by various packages e.g. bash package owns .bash_logout, .bash_profile, .bashrc ... I can't add dependency on bash into setup/filesystem, because these packages have to be installed as one of the first packages. This is the main reason for existence of rootfiles package - I keep the content of it as close as possible to the /etc/skel default content - with few modifications. 
Copying the content in setup or filesystem package is no go because of the dependencies (bash, coreutils). Will check where in dependency order is actually rootfiles package and possibly the copying could be done there somehow. If not, I'll likely WONTFIX that (as there is actually no content in /etc/skel at the time of root user creation).

fun scenario... 

Hm so the best scenario would be if we simply could copy those files at users first login instead of user creation ( pam_mkhomedir? ) while the workaround would be to create or <<EOF post install the content of the .bashrc files without the dependency on bash or other stuff in the setup package?

Note that even post install script brings usually the bash dependency automatically (as this is default "language" of the scriptlet).
I think posttrans scriptlet might work, I will check it when time allows - I think this is generally good idea (to allow admins to adjust the content as a part of kickstart of something). We'll see...

I could also take care of that and provide you with a patch if you just mention which component the mkdir -p /root and posttrans should be in?

I think mkdir -p /root is unnecessary - as this one will come from filesystem package anyway. Patch is not needed, correct component is the only uncertain thing - other than that it should be pretty easy to copy content of the directory via posttrans... As I said, rootfiles is probably correct option, I'll check that.

Simple
%posttrans
cp -a /etc/skel/* /root/
in rootfiles package should probably work. 

As it works after the transaction, packages should be in place and files should be copied. And simple reinstall of rootfiles will update everything to latest greatest. However, all files will be unowned (this is already the case for the home directories, so should not be a big issue).

This bug appears to have been reported against 'rawhide' during the Fedora 20 development cycle.
Changing version to '20'.

More information and reason for this action is here:
https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora20

? there is nothing preventing you from committing this change to F20

This bug appears to have been reported against 'rawhide' during the Fedora 20 development cycle.
Changing version to '20'.

More information and reason for this action is here:
https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora20

Commited and built in Rawhide as rootfiles-8.1-12.fc21 - let's see if everything is fine before the F20 change (I don't want to break the dependency chain).

Actually cp -na is not what we want, cp -ndpr is probably better (we don't want etc_t selinux context type on the files). rootfiles-8.1-13.fc21 is hopefully right one.

I'm seeing:

cp: cannot stat ‘/etc/skel/*’: No such file or directory

you probably want:

  cp -ndpr /etc/skel/. /root/

Yes, you are right, it worked for me because I had some not-hidden files in that directory. Thanks.

rootfiles-8.1-14.fc20 has been submitted as an update for Fedora 20.
https://admin.fedoraproject.org/updates/rootfiles-8.1-14.fc20

Package rootfiles-8.1-14.fc20:
* should fix your issue,
* was pushed to the Fedora 20 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing rootfiles-8.1-14.fc20'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2013-17486/rootfiles-8.1-14.fc20
then log in and leave karma (feedback).

rootfiles-8.1-14.fc20 has been pushed to the Fedora 20 stable repository.  If problems still persist, please make note of it in this bug report.