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

(As we did not run this process for some time, it could affect also pre-Fedora 23 development
cycle bugs. We are very sorry. It will help us with cleanup during Fedora 23 End Of Life. Thank you.)

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

*** Bug 1165982 has been marked as a duplicate of this bug. ***

Adding ooprala to CC - as this would likely mean downstream patch in bash - root $HOME is not different from $HOME of other users. As best solution I see alternative - more empty - atomic rootfiles package - to satisfy dependencies. Just removing the files can influence other shells as well, as they sometimes use ~/.bashrc files as well.

I think this is a very bad idea. As ovasik said, /root/.bashrc is just a $HOME .rc file like any other. Deleting it would probably break backwards compatibility in many cases. It would also mean we'd have to maintain a downstream change, since we could never ever justify it upstream. And if /root/.bashrc were to be merged with /etc/bashrc, how would you differentiate the definitions for root-only vs "globals"? A huge if PID == 0 statement? Also, non-root $HOME/.bashrc now already source /etc/bashrc in 99% cases. So would we read it twice, if user isn't root? Would we read /etc/bashrc on its own only if user == root? Would we ask everybody to change their .bashrc? Or change the code so $HOME/.bashrc gets sourced first, and if THAT sources /etc/bashrc, it doesn't get read again on its own?

All in all, IMHO this approach has several major flaws...

(In reply to Ondrej Oprala from comment #4)
> I think this is a very bad idea. As ovasik said, /root/.bashrc is just a
> $HOME .rc file like any other. Deleting it would probably break backwards
> compatibility in many cases.

Let's assume for the moment that we are able to make upgrades work.

> It would also mean we'd have to maintain a
> downstream change, since we could never ever justify it upstream. And if
> /root/.bashrc were to be merged with /etc/bashrc, how would you
> differentiate the definitions for root-only vs "globals"? A huge if PID == 0
> statement?

If we do this it would also likely make sense to move towards dropping .bashrc from /etc/skel as well.  (In fact, towards dropping all of /etc/skel by default, as everything else there looks very legacy too.

> Also, non-root $HOME/.bashrc now already source /etc/bashrc in
> 99% cases. So would we read it twice, if user isn't root? Would we read
> /etc/bashrc on its own only if user == root? Would we ask everybody to
> change their .bashrc?

Perhaps the simplest would be to change bash to source it by default if ~/.bashrc/~/.bash_profile does not exist.  That would keep existing installs working, while having the same default without the skel items.

The only thing I'm uncertain of is how to gracefully make the rootfiles package go away with traditional installs.  If we have another package Obsolete: rootfiles, that one could have a %postinst that checks whether a transition has been made, and if not copies the files from /usr/share/doc/setup/rootfiles/bashrc or so.

Still an issue.  

I guess if we don't want to make any changes into the traditional package, I could teach rpm-ostree to do this via `systemd-tmpfiles` or so.

Yes, if you will have package with shorter name that Provides: rootfiles in atomic and providing either no content (maybe just README explaining why this is the right thing for atomic), this should be just fine. I don't want to adjust the default non-atomic package, and same for Ondrej and bash...

(In reply to Ondrej Vasik from comment #7)
> Yes, if you will have package with shorter name that Provides: rootfiles in
> atomic and providing either no content (maybe just README explaining why
> this is the right thing for atomic), this should be just fine.

I'm not sure what you're suggesting here.  How would this package affect the behavior of the bash codebase?  It's not about satisfying dependencies - we also want bash to work on an OSTree/Atomic Host system obviously =)

> I don't want
> to adjust the default non-atomic package, and same for Ondrej and bash...

That's not a really useful approach to take to problem solving - you're not even willing to explore the solution space?  RpmOstree was an approved Change for F22: https://fedoraproject.org/wiki/Changes/RpmOstree

One thought is to put the initial creation of /root/.bashrc in Anaconda, i.e. it handles copying data from /usr/share/rootskel (e.g.).  That would work for yum/rpm-ostree managed host systems, cloud images, as well as Docker containers.  It wouldn't work for non-Docker containers that don't use Anaconda, but I think we could let that slide.

I can't really think of a solution that doesn't involve patching bash in some way for the general case.

One thing I was wondering - what does Debian do here?  I dimly recalled they didn't have an equivalent to `rootfiles`.

It turns out bash already has code for this:

/* System-wide .bashrc file for interactive shells. */
#define SYS_BASHRC "/etc/bash.bashrc"

Turning it on didn't work though, not immediately sure why - but at least this shows that there is precedent.  Are you willing to help with this?

(In reply to Colin Walters from comment #8)
> (In reply to Ondrej Vasik from comment #7)
> > Yes, if you will have package with shorter name that Provides: rootfiles in
> > atomic and providing either no content (maybe just README explaining why
> > this is the right thing for atomic), this should be just fine.
> 
> I'm not sure what you're suggesting here.  How would this package affect the
> behavior of the bash codebase?  It's not about satisfying dependencies - we
> also want bash to work on an OSTree/Atomic Host system obviously =)

Basically - rootfiles gets pulled in based on the dependencies. If you provide some other dummy skeleton package that behaves your way, rootfiles will not be in the installation transaction and therefore you will not have any issue later on.
 
> > I don't want
> > to adjust the default non-atomic package, and same for Ondrej and bash...
> 
> That's not a really useful approach to take to problem solving - you're not
> even willing to explore the solution space?  RpmOstree was an approved
> Change for F22: https://fedoraproject.org/wiki/Changes/RpmOstree

There are many such approved changes that were never finished in full scale of Fedora - e.g. UsrMove is still completely unfinished (as many packages still depend on /bin and many packages still install into /bin (although through symlink it ends up in /usr/bin).
For rootfiles, I don't see this is broken - but I agree it should be further investigated on bash side. Unfortunately, bash maintainer left Red Hat and we are now in transition state. I'll ask the new bash maintainer for further investigation once he'll be able to deal with that - meanwhile I doubt I will have time "to explore solution space" due to other priorities.
 
> One thought is to put the initial creation of /root/.bashrc in Anaconda,
> i.e. it handles copying data from /usr/share/rootskel (e.g.).  That would
> work for yum/rpm-ostree managed host systems, cloud images, as well as
> Docker containers.  It wouldn't work for non-Docker containers that don't
> use Anaconda, but I think we could let that slide.
> 
> I can't really think of a solution that doesn't involve patching bash in
> some way for the general case.

Thanks for the suggestion and pointers in your next comment. I'll move it to bash, as the investigation will be done on bash side. I don't think we should modify the rootfiles package here. And any change in bash should not affect legacy users.

This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.

The F24 Atomic RC-1.1 is showing this problem. Is there any progress on deciding how to go about fixing this bug?

https://github.com/CentOS/sig-atomic-buildscripts/pull/148

This message is a reminder that Fedora 23 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 23. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as EOL if it remains open with a Fedora  'version'
of '23'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 23 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Fedora 23 changed to end-of-life (EOL) status on 2016-12-20. Fedora 23 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.

Would still prefer an in-package fix, since we have to carry the workaround in multiple places.

https://pagure.io/fedora-kickstarts/pull-request/123

I have modified bash.spec file to source /etc/bashrc by default [1] and did a test build at [2].

However this will cause double sourcing of /etc/bashrc, as it is being sourced for root and normal user bashrc's in rootfiles[3] and setup packages. Leaving needinfo for ovasik to check if it would be ok to modify these packages to not source /etc/bashrc.

[1] https://github.com/fedora-testing/bash/commit/f18b6bcccaef819c6775834db8b8a40dd1a75418
[2] https://koji.fedoraproject.org/koji/taskinfo?taskID=18968219
[3] http://pkgs.fedoraproject.org/cgit/rpms/rootfiles.git/tree/dot-bashrc#n11

Default .bashrc file for new users is coming from bash package itself (and not setup package). I modified the commit to fix default .bashrc for new users [1]. 

[1] https://github.com/fedora-testing/bash/commit/87ac935a6643a9afee44a9575771418d7be15fcb

Even if we change rootfiles/setup, we'll have to deal with compatibility with people who have modified those files.  In particular, changing setup won't change any existing user's .bashrc.

Maybe something like this?

[root@icarus ~]# diff -u /usr/etc/bashrc /etc/bashrc
--- /usr/etc/bashrc	1969-12-31 19:00:00.000000000 -0500
+++ /etc/bashrc	2017-04-13 11:00:12.792861611 -0400
@@ -8,6 +8,9 @@
 # /etc/profile.d/ to make custom changes to your environment, as this
 # will prevent the need for merging in future updates.
 
+if [ -z "$BASHRC_SOURCED" ]; then
+BASHRC_SOURCED=1
+
 # are we an interactive shell?
 if [ "$PS1" ]; then
   if [ -z "$PROMPT_COMMAND" ]; then
@@ -89,4 +92,5 @@
     unset i
     unset -f pathmunge
 fi
+fi
 # vim:ts=4:sw=4

(In reply to Siteshwar Vashisht from comment #18)
> I have modified bash.spec file to source /etc/bashrc by default [1] and did
> a test build at [2].
From the brief looking at the specfile change, it looks like this is a parameter for the compilation of bash itself. Does it mean that this change will be built-in to the bash?

How exactly will it affect users that have their bashrc files modified for their needs?

If there will be an alteration in behaviour for users that use their own bashrc files, we should let people know in advance about it - at least in Fedora devel mailing list.

> From the brief looking at the specfile change, it looks like this is a parameter for the compilation of bash itself. Does it mean that this change will be built-in to the bash?
Yes, it is built into the shell. With this change bash will always source /etc/bashrc file when it is started.

> How exactly will it affect users that have their bashrc files modified for their needs?
It may break the user configurations if they do not wish to source default /etc/bashrc. So they may have to override any default configurations from /etc/bashrc.

> If there will be an alteration in behaviour for users that use their own bashrc files, we should let people know in advance about it - at least in Fedora devel mailing list.
I agree with this point. However I am still pondering over the idea and still not sure if we should ship this change into Fedora.

(In reply to Siteshwar Vashisht from comment #22)
> I agree with this point. However I am still pondering over the idea and
> still not sure if we should ship this change into Fedora.
I see. In that I would suggest to really bring this topic to Fedora devel mailing list to get some feedback on it (you can put me into CC), because I see the reasons for this change to be still valid...

Anyway, thanks for the reply. :)

If we go that way, I'm fine with changing rootfiles package too... as it should be as close as possible to /etc/skel/ for normal users.
For the comment #20... hmmms, why not... works for me... and I don't see any reasons why I shouldn't make this update even before bash with /etc/bashrc sourcing will make it to the Fedora. It will just prevent potential accidental doublesourcing...

A downside of https://bugzilla.redhat.com/show_bug.cgi?id=1193590#c20 is that a new random environment variable appears in everyone's shells.  It's not going to be a *problem* but it just feels ugly.

https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/D3SNETBTXXZL4ZABCLNEQRCST2NQE54T/

(In reply to Colin Walters from comment #25)
> A downside of https://bugzilla.redhat.com/show_bug.cgi?id=1193590#c20 is
> that a new random environment variable appears in everyone's shells.  It's
> not going to be a *problem* but it just feels ugly.

It should be possible to examine the BASH_SOURCE array to detect if /etc/bashrc is being sourced from a ~/.bashrc.

# printf 'echo "${BASH_SOURCE[@]}"' >> /etc/bashrc

$ source ~/.bashrc
/etc/bashrc /home/scop/.bashrc

*** Bug 1462379 has been marked as a duplicate of this bug. ***

bash-4.4.12-11.fc27 has been submitted as an update to Fedora 27. https://bodhi.fedoraproject.org/updates/FEDORA-2017-36a20b7132

bash-4.4.12-11.fc27 has been pushed to the Fedora 27 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2017-36a20b7132

bash-4.4.12-11.fc27 has been submitted as an update to Fedora 27. https://bodhi.fedoraproject.org/updates/FEDORA-2017-36a20b7132

bash-4.4.12-11.fc27 has been pushed to the Fedora 27 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2017-36a20b7132

(In reply to Siteshwar Vashisht from comment #22)
> > How exactly will it affect users that have their bashrc files modified for their needs?
> It may break the user configurations if they do not wish to source default
> /etc/bashrc. So they may have to override any default configurations from
> /etc/bashrc.

This absolutely breaks user environments if they do not wish to source the "helpful" additions from /etc/bashrc and /etc/profile.d -- some of them in ways which cannot be overridden, for example the 'history -a' in the default /etc/bashrc will write a history file before the user has an opportunity to change HISTFILE to another location.

This is a regression.  Please treat it as such and revert the change.

FWIW -- not necessarily to object to this, but just to provide some related data: There's some related discussion in bash-completion upstream about this, and I suspect this change might be the reason our rawhide CI run has gone red/wrong right from the start (haven't had a chance to look closer yet):

https://github.com/scop/bash-completion/pull/117
https://travis-ci.org/scop/bash-completion/jobs/280267000

bash-4.4.12-11.fc27 has been pushed to the Fedora 27 stable repository. If problems still persist, please make note of it in this bug report.

Any chance of this being revisited?  There's an awful lot of stuff in /etc/bashrc and /etc/profile.d/* that isn't easily circumvented and/or makes irreversible changes.

(In reply to Rob Foehl from comment #36)
> Any chance of this being revisited?  There's an awful lot of stuff in
> /etc/bashrc and /etc/profile.d/* that isn't easily circumvented and/or makes
> irreversible changes.

Unfortunately, this cannot be fixed in bash.  We need to file bugs against other packages that install the unwanted profile scripts to move them elsewhere.  Not even /etc/bashrc is installed by bash (I think it should but who cares).

(In reply to Kamil Dudka from comment #37)
> Unfortunately, this cannot be fixed in bash.  We need to file bugs against
> other packages that install the unwanted profile scripts to move them
> elsewhere.  Not even /etc/bashrc is installed by bash (I think it should but
> who cares).

Right, the underlying problems should be corrected in each software package that ships something invasive, including setup for /etc/bashrc.  Unfortunately, the chances of that happening any time soon are slim, and the ultimate issue is that this change in bash represents a significant alteration of existing behavior, by making it impossible to avoid the system scripts.  The "users will just have to deal with it" attitude doesn't really work here.

I see there is one problem listed in comment 33 that should be fixed in setup package. Would it be possible for you to explain any other issues that you are facing ? I did not receive much feedback when I proposed this change in fedora-devel list[1] earlier. I would be interested in knowing if this change causes any major breakage.

[1] https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/D3SNETBTXXZL4ZABCLNEQRCST2NQE54T/

(In reply to Siteshwar Vashisht from comment #39)
> I see there is one problem listed in comment 33 that should be fixed in
> setup package. Would it be possible for you to explain any other issues that
> you are facing ? I did not receive much feedback when I proposed this change
> in fedora-devel list[1] earlier. I would be interested in knowing if this
> change causes any major breakage.

Let's be careful to distinguish between issues in the system scripts, and the inability to avoid sourcing them, which is the fundamental concern with this change.  A deliberate choice to avoid the system scripts by not sourcing /etc/bashrc from ~/.bashrc -- which previously worked all the way back to Red Hat Linux in the late 90s -- is no longer possible.  I'd still call that a regression.

That aside, on a default Workstation install of Fedora 27 Beta, at least the following issues exist in the system scripts:

- /etc/bashrc unconditionally calls 'history -a' before the HIST* shell variables are set, leading to a default history file being created and/or data loss in the case where the user intends to set larger-than-default values for HISTSIZE or HISTFILESIZE, or enables use of history timestamps via HISTTIMEFORMAT.

- /etc/profile.d/bash_completion.sh unconditionally loads the system-provided bash_completion script with no opportunity[1] to customize or use an alternate; cleaning up everything this does after the fact is extremely laborious.

- /etc/profile.d/lang.sh unsets variables it didn't set.

- /etc/profile.d/modules.sh has similar issues to bash_completion.sh, with additional detours through various other conditionally sourced scripts.

- /etc/profile.d/scl-init.sh defines functions that rely on other generically-named functions having been previously defined elsewhere.

- /etc/profile.d/vte.sh overwrites at least PROMPT_COMMAND in bash, ironically despite it being set non-destructively in /etc/bashrc.

The rest of the scripts in a default Workstation install just litter the environment with various items of questionable usefulness; annoying, but at least relatively easy to clean up.  However, according to a 'dnf provides /etc/profile.d/*.sh' query, there are currently some 100 packages in Fedora 27 that install at least one of these scripts.  Combing through all of them for unwanted changes, especially after each new package release, is a combinatorial problem at best.


[1] Not strictly true, but doing otherwise relies on a quirk of /etc/profile.d/bash_completion.sh unnecessarily testing for the progcomp option being enabled in the calling shell.

Yeah, OK.  As the person filing the bug here, I'd agree we should back this out based on comment #40 and others. We still have the workarounds in place for Fedora Atomic Host, as ugly as they are.

One thing I'd like to understand better is the behavior difference vs Debian in <https://bugzilla.redhat.com/show_bug.cgi?id=1193590#c9>.

(In reply to Rob Foehl from comment #40)
> - /etc/bashrc unconditionally calls 'history -a' before the HIST* shell
> variables are set, leading to a default history file being created and/or
> data loss in the case where the user intends to set larger-than-default
> values for HISTSIZE or HISTFILESIZE, or enables use of history timestamps
> via HISTTIMEFORMAT.

The above command should be removed from /etc/bashrc IMO.

> - /etc/profile.d/bash_completion.sh unconditionally loads the
> system-provided bash_completion script with no opportunity[1] to customize
> or use an alternate; cleaning up everything this does after the fact is
> extremely laborious.
> 
> - /etc/profile.d/lang.sh unsets variables it didn't set.
> 
> - /etc/profile.d/modules.sh has similar issues to bash_completion.sh, with
> additional detours through various other conditionally sourced scripts.
> 
> - /etc/profile.d/scl-init.sh defines functions that rely on other
> generically-named functions having been previously defined elsewhere.
> 
> - /etc/profile.d/vte.sh overwrites at least PROMPT_COMMAND in bash,
> ironically despite it being set non-destructively in /etc/bashrc.

The underlying problem here is that /etc/bashrc sources scripts from /etc/profile.d for non-login shells while the same scripts are sourced from /etc/profile for login shells.  It does not make much sense...

I propose to revert this change for f27.  We can consider fixing it later.

The immediate workaround is to run non-login shells with the --norc option of bash.  Login shells do not seem to be affected by this change.

(In reply to Rob Foehl from comment #40)
> - /etc/profile.d/lang.sh unsets variables it didn't set.

Yeah, regarding this, we were discussing before with Siteshwar if we could just drop it completely (it's a script currently from initscripts). Unfortunately we can't.

That script is being used as a workaround for some incorrect LANG settings that could potentionally result in unreadable shell/terminal for some languages.

(In reply to Kamil Dudka from comment #42)
> (In reply to Rob Foehl from comment #40)
> > - /etc/bashrc unconditionally calls 'history -a' before the HIST* shell
> > variables are set, leading to a default history file being created and/or
> > data loss in the case where the user intends to set larger-than-default
> > values for HISTSIZE or HISTFILESIZE, or enables use of history timestamps
> > via HISTTIMEFORMAT.
> 
> The above command should be removed from /etc/bashrc IMO.

Definitely.  That's probably the worst offender among the myopic defaults in the system scripts.

> The underlying problem here is that /etc/bashrc sources scripts from
> /etc/profile.d for non-login shells while the same scripts are sourced from
> /etc/profile for login shells.  It does not make much sense...
> 
> I propose to revert this change for f27.  We can consider fixing it later.
> 
> The immediate workaround is to run non-login shells with the --norc option
> of bash.  Login shells do not seem to be affected by this change.

That's not possible in a lot of cases, notably via ssh: it always starts "the shell" from the passwd database, as a login shell when a pty is attached, and without the ability to pass extra arguments in any case.

Login shells do wind up sourcing everything from /etc/profile.d, which is still pretty obnoxious.  The biggest problem I've run into is the early loading of the bash_completion script, which I've been working around using the shopt -u progcomp hack mentioned previously.  I still haven't found a way to avoid the system scripts in all cases, albeit not for lack of trying -- wrappers to avoid loading the system defaults suffice for vim and ssh, but the shell is a bit harder to cope with consistently.

In general, it seems like a lot of the stuff in /etc/profile.d on Fedora is not really related to the shell and instead trying to set environmental defaults, which makes a broad assumption about interstitial shells having an opportunity to modify the environment.  To the point in comment #41 (and comment #9), Debian seems to be a *lot* more conservative about what lands in these scripts in the first place.  In fact, the aforementioned bash_completion workaround apparently originated in Debian[1], and in general they do very little in the unconditionally sourced /etc scripts, instead shipping most of the "defaults" in a relatively lengthy /etc/skel/.bashrc.

I'd be willing to put some effort into tracking these down and opening bugs to move the heavy-handed stuff out of the system scripts, as time permits...  Meanwhile, there appears to be some consensus here to revert the /etc/bashrc change, but no updates in the package.  What's the status for F27?

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=593835

Sorry I got busy with other stuff. It seems likely we will end up reverting this change. I need to finalize the discussion with setup maintainer and this should be done by end of this week.

bash-4.4.12-12.fc27 has been submitted as an update to Fedora 27. https://bodhi.fedoraproject.org/updates/FEDORA-2017-5bf6183242

bash-4.4.12-12.fc27 has been pushed to the Fedora 27 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2017-5bf6183242

Proposed as a Blocker for 27-final by Fedora user svashisht using the blocker tracking app because:

 In Fedora 26 and earlier releases /etc/bashrc is sourced by user's ~/.bashrc. As a fix for bug 1193590 I made an update in Fedora 27 to source /etc/bashrc directly when bash starts and removed it from sourcing in user's ~/.bashrc. Fedora users objected to this change so I had to revert it back to old behavior.

Update for reverted changes[1] is still not pushed to stable. If we make a release without this update and users do a clean install from it, their ~/.bashrc will not source /etc/bashrc and this update will break their systems. We already have a report[1] about it.

So I recommend to add this update[1] to Fedora 27 GA release.

[1] https://bodhi.fedoraproject.org/updates/FEDORA-2017-5bf6183242
[2] https://bodhi.fedoraproject.org/updates/bash-4.4.12-12.fc27#comment-686770

(In reply to Fedora Blocker Bugs Application from comment #48)
>  In Fedora 26 and earlier releases /etc/bashrc is sourced by user's
> ~/.bashrc. As a fix for bug 1193590 I made an update in Fedora 27 to source
> /etc/bashrc directly when bash starts and removed it from sourcing in user's
> ~/.bashrc. Fedora users objected to this change so I had to revert it back
> to old behavior.

So, to be clear: the bashrc for new accounts on newly-installed systems will not source /etc/bashrc in user sessions, causing them to be broken, unless 

https://bodhi.fedoraproject.org/updates/FEDORA-2017-5bf6183242

is included in the release?

Can you more specifically define "broken" in this case?

> Some of So, to be clear: the bashrc for new accounts on newly-installed systems will not source /etc/bashrc in user sessions, causing them to be broken, unless 
> 
> https://bodhi.fedoraproject.org/updates/FEDORA-2017-5bf6183242
> is included in the release?

Yes, you are right.

> Can you more specifically define "broken" in this case?

It's just that on affected systems /etc/bashrc will stop being sourced in newly setup accounts.

> It's just that on affected systems /etc/bashrc will stop being sourced in newly setup accounts.

The consequences of which are... PROMPT_COMMAND not being set? What else?

/etc/bashrc also sources scripts under /etc/profile.d, so none of the configurations set up with these scripts will be used. Some packages use this directory to set up custom configurations. So functionality of other packages may be affected too.

Discussed at 2017-11-01 to 2017-11-02 Fedora 27 Go/No-Go meeting, acting as a blocker review meeting: https://meetbot-raw.fedoraproject.org/fedora-meeting-1/2017-11-02/f27-final-and-server-beta-go-no-go-meeting.2017-11-02-17.00.html . Accepted as a blocker, on the basis that it's a critpath issue of 'high' severity (at least, the consequences of changing this with a post-release update would certainly be 'high' or 'critical') with no feasible workaround.

Basically, we don't think it would be acceptable at all to ship with bash sourcing /etc/bashrc and ~/.bashrc *not* doing it, then ship an update which caused bash not to source /etc/bashrc any more, as the effect of this would be that user accounts for every F27 install done before the update would break when the update was applied.

We also don't think it's a good idea to ship with the change to bash sourcing /etc/bashrc directly and reject the reversion; we agree with the assessment from this bug that the change clearly wasn't fully thought through and isn't ready for primetime. We don't want to ship a release with the change at present.

That means the only viable choice is to revert the change, i.e. accept this as a blocker bug, and pull the update into the F27 Final compose.

Marking CommonBugs to denote that we must also document the transition for affected F27 pre-release users.

bash-4.4.12-12.fc27 has been pushed to the Fedora 27 stable repository. If problems still persist, please make note of it in this bug report.