Bug 1514048

Summary: On fresh installation login script prints "Attempting to create directory /root/perl5"
Product: Red Hat Enterprise Linux 7 Reporter: Ray Strode [halfline] <rstrode>
Component: perl-local-libAssignee: perl-maint-list
Status: CLOSED WONTFIX QA Contact: BaseOS QE - Apps <qe-baseos-apps>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 7.5CC: ppisar
Target Milestone: rcKeywords: FutureFeature, Reopened
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2018-03-02 15:41:17 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Ray Strode [halfline] 2017-11-16 14:55:59 UTC
I just did a 7.5 install, i think i picked Developer and Creative workstation.

When I su'd to root in a terminal it printed the message

"Attempting to create directory /root/perl5"

This looks bad. If perl5 has to exist straight in root's home directory, it should create it silently not print wishy-washy messages about how it's trying to create it.

But I do wish this perl5 directory was a dot dir of some sort instead of straight in the home dir, unhidden.

Comment 2 Petr Pisar 2017-11-16 16:02:35 UTC
The message comes from perl-local-lib package.

If you do not want to create the directory, uninstall perl-homedir package or set PERL_HOMEDIR=0 in /etc/sysconfig/perl-homedir or ~/.perl-homedir configuration file.

If you don't like the directory name, you can offer better name to he local-lib authors <http://search.cpan.org/~haarg/local-lib/>. We cannot change the name because of the compatibility.

The "Attempting to create directory" message is printed only on the first time when the directory is created. Once created, there is no message anymore. In my opinion it's good habit to inform the user when a script touches his home directory and I'm not going to suppress the message.

Again you can offer your advice to local-lib authors.

If still think the message should not be printed, please contact Red Hat support to help you to evaluate your request properly.

Comment 3 Ray Strode [halfline] 2017-11-16 19:12:15 UTC
I disagree completely. It looks like a debug message. why does it go to standard error? Why does it say it's /attempting/ to do it?  Does it think it's likely to fail? Why wouldn't it try first and only report a problem if there was one? It's just weird.

Should GNOME throw up a dialog saying it created ~/Pictures and ~/Desktop the first time you log in? Transparency can be a good thing, but this takes it too far imo.

Having said that, I assumed fixing this would be non-controversial. It apparently is controverial, so I'm not going to pursue this further.

Comment 4 Petr Pisar 2017-11-20 10:27:20 UTC
You are right it should not go to stderr by default. Later local-lib release added an option for suppressing the message. I asked authors which solution they like more.

Comment 5 Petr Pisar 2018-03-02 15:41:17 UTC
Printing to stderr is a must because stdout output is passed to shell's eval. I'm sorry for my bad previous advise. (Well one could format the message as a comment with leading # character, but then message would look weird.)

Also upstream is reluctant to suppress the message by default.

We could try to port an option for suppressing the message. But to align to upstream and to previous installation, we cannot won't change the default. You could activate the suppression option yourself.

But since this issue has very low impact and no customer has requested this change I close this report again. If want the change to happen you have to go to Red Hat support. Bugzilla is not a support tool.

Comment 6 Ray Strode [halfline] 2018-03-02 16:17:10 UTC
i'm a coworker, not a customer.   i don't have a support contract with Red Hat, just a vested interest in the out of the box experience being good.

What's pulling in perl-homedir by default? Maybe we should take it out?  alternatively maybe we should add perl5/ to /etc/skel ?

Comment 7 Petr Pisar 2018-03-05 09:39:01 UTC
It's pulled in by additional-devel package group. It's also an optional part of perl-runtime package group. If you don't like perl-homedir, either don't install that groups or request a change in comps group definitions (probably a "distribution" component here in Bugzilla).