Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 259882 - bash-completion-20081219 does neither replace nor complain /etc/profile.d/bash-completion.sh
Summary: bash-completion-20081219 does neither replace nor complain /etc/profile.d/bas...
Status: RESOLVED FIXED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: New packages (show other bugs)
Hardware: All Linux
: High normal (vote)
Assignee: Jeremy Olexa (darkside) (RETIRED)
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: 259724 261959
  Show dependency tree
 
Reported: 2009-02-22 10:19 UTC by Ales Friedl
Modified: 2009-03-10 09:30 UTC (History)
2 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments
bash-completion from bc2006 renamed to bash-completion.sh by bc2009 (bash-completion.sh,724 bytes, text/plain)
2009-02-24 08:42 UTC, Ales Friedl
Details
New bash-completion.sh from 2009 ready to dispatch (._cfg0000_bash-completion.sh,1.64 KB, text/plain)
2009-02-24 08:44 UTC, Ales Friedl
Details
record in /etc/config-archive/etc/profile.d/ created after dispatching (bash-completion.sh,v,2.50 KB, text/plain)
2009-02-24 08:49 UTC, Ales Friedl
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Ales Friedl 2009-02-22 10:19:27 UTC
Hello, If I install bash-completion-20081219, it does not complain about already existing /etc/profile.d/bash-completion.sh. It does not replace this file either.

If there already is (an orphaned?) file e.g. from bash-completion-20050121-r10, completion will not work and will fire strange bash errors:

$su
Password or swipe finger:
bash: [: !=: unary operator expected
bash: /root/.bash_completion.d/base: line 117: syntax error in conditional expression: unexpected token `('
bash: /root/.bash_completion.d/base: line 117: syntax error near `*$1+(['
bash: /root/.bash_completion.d/base: line 117: `    [[ "$( bind -v )" = *$1+([[:space:]])on* ]]'
bash: /root/.bash_completion.d/gentoo: line 350: syntax error in conditional expression: unexpected token `('
bash: /root/.bash_completion.d/gentoo: line 350: syntax error near `"-@(V'
bash: /root/.bash_completion.d/gentoo: line 350: `    [[ ${COMP_LINE} == *" "-@(V|-version)* ]] && version_mode=1'
bash: /root/.bash_completion.d/gkrellm: line 14: syntax error near unexpected token `('
bash: /root/.bash_completion.d/gkrellm: line 14: `              -@(t|-theme))'

According to errors seen, bug #250921 where "some people have problems with bashcomp and some does not have" would be related to this. Maintainers of #259724 should take care also. Thanks.

Reproducible: Always

Steps to Reproduce:
1. echo > /etc/profile.d/bash-completion.sh
2. emerge =bash-completion-20081219
3. ls -ld /etc/profile.d/bash-completion.sh
-rw-r--r-- 1 root root 1 Feb 22 11:07 /etc/profile.d/bash-completion.sh




To fix or to emerge 20081219 safely:
rm /etc/profile.d/bash-completion.sh
emerge =bash-completion-20081219
Comment 1 Jeremy Olexa (darkside) (RETIRED) archtester gentoo-dev Security 2009-02-23 03:58:56 UTC
How did you hit this?

Of course, if you emerge bash-completion then mess with /etc/profile.d/bash-completion.sh, you will need to use emerge --noconfmem bash-completion to get the original file back. So, your steps to reproduce are invalid if you already merged bash-completion-200812* before trying to reproduce it.
Comment 2 Ales Friedl 2009-02-23 05:13:45 UTC
Well, I did not know about --noconfmem, however I am able to reproduce it. It has something to do with dispatch-conf, It did not replace old bash-completion.sh with the new one, but kept the old one.
(If I had checked ._confblah files manually, it wouldn't happend, but I didn't).

Steps to reproduce:
1. emerge =app-shells/bash-completion-20081218 

(merged /etc/profiles.d/bash-completion.sh with file header bash-completion,v 1.7 2004/11/12 (no ".sh" here, but maybe it is not important)

2. emerge =app-shells/bash-completion-20060301

(merged /etc/profiles.d/bash-completion, with file header bash-completion,v 1.7,
 previous bash-completion.sh is not unmerged, I suppose this is ok becouse it is a config file)

3. emerge =app-shells/bash-completion-20081219

(I am informed about new config file, ._cfg000_bash-completion.sh with header bash-completion.sh,v 1.3 2008/06/15, which is ready to dispatch in /etc/profiles.d. It has lower revision number even though it is newer, does it matter?)

bash# ls -la /etc/profile.d/
-rwxr-xr-x  1 root root  724 Feb 23 05:41 bash-completion.sh
-rwxr-xr-x  1 root root 1683 Feb 22 10:16 ._cfg0000_bash-completion.sh
)

dispatch-conf

RCS file: /etc/config-archive/etc/profile.d/bash-completion.sh,v
1.1 locked
done
/etc/config-archive/etc/profile.d/bash-completion.sh,v  <--  /etc/config-archive/etc/profile.d/bash-completion.sh
file is unchanged; reverting to previous revision 1.1
done
/etc/config-archive/etc/profile.d/bash-completion.sh,v  -->  /etc/config-archive/etc/profile.d/bash-completion.sh
revision 1.1.1.1
done
RCS file: /etc/config-archive/etc/profile.d/bash-completion.sh,v
retrieving revision 1.1.1.1
retrieving revision 1.1
Merging differences between 1.1.1.1 and 1.1 into /etc/config-archive/etc/profile.d/bash-completion.sh; result to stdout
RCS file: /etc/config-archive/etc/profile.d/bash-completion.sh,v
1.1.1.1 locked
done
/etc/config-archive/etc/profile.d/bash-completion.sh,v  <--  /etc/config-archive/etc/profile.d/bash-completion.sh
file is unchanged; reverting to previous revision 1.1.1.1
done

Voila... I have wrong (old) bash-completion.sh.

In this case the file was dispatched automatically, but strange is that even though once I merged these files manually (dispatch-conf asked me), incorrect config was finally merged so I ended up again with the wrong one!?)


dispatch.conf:
replace-cvs=yes
replace-wscomments=no
replace-unmodified=yes
ignore-previously-merged=yes
Comment 3 Ales Friedl 2009-02-23 05:45:43 UTC
Additional notes:

1) Step 2 is not needed, emerging 20081218 and than 20081219(-r1) is enough.
I do not know how dispatch-conf works exactly, if it looks at revesion numbers in header too, it might be fooled becouse the newer file has lower rev. number. Looks like it does not consider ._cfg0000_foo.sh file being newer than foo.sh, even though it is, and it simply ends with foo.sh, ._cfg0000_foo.sh is "ignored" as if it never was there :(

2) 200811218 is not in portage now, but it was when I upgraded to 20081219.
Comment 4 Ales Friedl 2009-02-23 14:42:48 UTC
Steps to reproduce the same behavior with packages present in portage:

Clean system (bashcomp unmerged, bash-completion{,.sh} unmerged by emerge too, record file in config-archive deleted manually (_hope_ this can be done?)

1. emerge =bash-completion-20060301
bash-completion fetched

ls -la /etc/profile.d/
-rwxr-xr-x  1 root root  724 Feb 23 15:25 bash-completion

3. emerge =bash-completion-20081219-r1 && dispatch-conf
bash-completion.sh merged (this is the correct one, fine)

ls -la /etc/profile.d/
-rwxr-xr-x  1 root root 1683 Feb 23 15:25 bash-completion.sh

4. emerge =bash-completion-20060301

// bash-completion fetched
// bash-completion.sh unmerged (as it was not touched), but record in config-archive remains...
ls -la /etc/profile.d/
-rwxr-xr-x  1 root root  724 Feb 23 15:27 bash-completion

5. emerge =bash-compleiton-20081219-r1 && dispatch-conf // now it it is different
bash-completion.sh merged, but now with wrong result (probably becouse of record in config-archive?); bashcomp not working and I am almost not able to get out of this.

Ad 5:

before dispatch-conf:
ls -la /etc/profile.d/
-rwxr-xr-x  1 root root 1683 Feb 23 15:28 ._cfg0000_bash-completion.sh
-rwxr-xr-x  1 root root  724 Feb 23 15:27 bash-completion.sh

seems fine but after:
dispatch-conf
RCS file: /etc/config-archive/etc/profile.d/bash-completion.sh,v
1.1 locked
done
/etc/config-archive/etc/profile.d/bash-completion.sh,v  <--  /etc/config-archive/etc/profile.d/bash-completion.sh
file is unchanged; reverting to previous revision 1.1
done
/etc/config-archive/etc/profile.d/bash-completion.sh,v  -->  /etc/config-archive/etc/profile.d/bash-completion.sh
revision 1.1.1.1
done
RCS file: /etc/config-archive/etc/profile.d/bash-completion.sh,v
retrieving revision 1.1.1.1
retrieving revision 1.1
Merging differences between 1.1.1.1 and 1.1 into /etc/config-archive/etc/profile.d/bash-completion.sh; result to stdout
RCS file: /etc/config-archive/etc/profile.d/bash-completion.sh,v
1.1.1.1 locked
done
/etc/config-archive/etc/profile.d/bash-completion.sh,v  <--  /etc/config-archive/etc/profile.d/bash-completion.sh
file is unchanged; reverting to previous revision 1.1.1.1
done

ls -la /etc/profile.d/
-rwxr-xr-x  1 root root  724 Feb 23 15:27 bash-completion.sh (the wrong one)

Maybe it is a bit unrealistic up/down/upgrade, but something similar happend to me, I had 2006, than 20081218, but this one was removed from portage, so I was downgraded "automatically" back to 2006, than I upgraded manually to 20091219, which did not work... Quite easy to get there...
Comment 5 Jeremy Olexa (darkside) (RETIRED) archtester gentoo-dev Security 2009-02-23 15:41:25 UTC
(In reply to comment #4)

> me, I had 2006, than 20081218, but this one was removed from portage, so I was
> downgraded "automatically" back to 2006, than I upgraded manually to 20091219,
> which did not work... Quite easy to get there...
> 

Well yes, I'm not going to keep around bad ~arch versions. It is a known "non-support case" to only selectively use ~arch on some packages.

I'm thinking that anyone that hits this bug in the future so re-merge bash-completion with "emerge --noconfmem bash-completion"

I have upgraded from 20060301 to 20081218 without issues and that will be the upgrade path for stable users.
Comment 6 Ales Friedl 2009-02-23 16:30:32 UTC
(In reply to comment #5)
> I'm thinking that anyone that hits this bug in the future so re-merge
> bash-completion with "emerge --noconfmem bash-completion"

Yes, solution seems to be simple, it was only hard to find out where was the problem.

> I have upgraded from 20060301 to 20081218 without issues and that will be the
> upgrade path for stable users.

I think that ...18 was removed and ...19 will be stabilized? But I do not know. 

Anyhow, thanks you've looked at this! Yes, upgrade is working (if there is not downgrade which removes bash-completion.sh in between). I do not know if downgrade is support case :-D but maybe in stable version it will be working too. Thanks again, bash completion is very useful...
Comment 7 Jeremy Olexa (darkside) (RETIRED) archtester gentoo-dev Security 2009-02-23 19:36:40 UTC
(In reply to comment #6)

> > I have upgraded from 20060301 to 20081218 without issues and that will be the
> > upgrade path for stable users.
> 
> I think that ...18 was removed and ...19 will be stabilized? But I do not know. 

Yea, sry. I mistyped that.

> 
> Anyhow, thanks you've looked at this! Yes, upgrade is working (if there is not
> downgrade which removes bash-completion.sh in between). I do not know if
> downgrade is support case :-D but maybe in stable version it will be working
> too. Thanks again, bash completion is very useful...
> 

Yea, it will be nice to improve the state of bash-completion in Gentoo =D

I'm going to resolve this bug, after chatting with some other fellow devs..we attributed this particualr case to a combination of dispatch-conf wierdness and a nasty interaction with up/down/upgrade things happening.

The good news is that b-c-20081219-r1 should be able to be stabilized within a week or so. Thanks for the report and I'll direct similar bugs to this one if the need arises.
Comment 8 Zac Medico gentoo-dev 2009-02-23 22:12:19 UTC
(In reply to comment #4)
I followed your steps but everything seemed to work fine for me, but I don't have rcs enabled for dispatch-conf so maybe it's somehow related to the rcs support.
Comment 9 Ales Friedl 2009-02-24 08:42:29 UTC
Created attachment 182994 [details]
bash-completion from bc2006 renamed to bash-completion.sh by bc2009
Comment 10 Ales Friedl 2009-02-24 08:44:09 UTC
Created attachment 182995 [details]
New bash-completion.sh from 2009 ready to dispatch
Comment 11 Ales Friedl 2009-02-24 08:49:06 UTC
Created attachment 182997 [details]
record in /etc/config-archive/etc/profile.d/ created after dispatching

If you start with empty /etc/config-archive/etc/profile.d/, 
after dispatch-conf, record in rcs is the same as in this attachment and bash-completion is merged fine. But if bash-copletion is downgraded and upgraded again, situation is the same as at the begining, except that there already is a record in /etc/config-archive/etc/profile.d/. Now dispatch-conf fails and result is the old config file, no questions asked.
Comment 12 Ales Friedl 2009-02-24 08:58:13 UTC
I have added some attachments, if someone from dispatch-conf is interested. Both .sh files are "created" by bc2009, the old one is renamed from old bash-completion script, the new one is normally pulled in by bc2009. RCS record is created after merging. If you then move .sh files again there (will happed after downgrade and upgrade bc) to dispatch them again, dispatch-conf fails (probably becouse of the rcs record).

It can be tested e.g. if you move bash-completion.sh and ._cfg0000_bash-completion.sh to /etc/foo and "move/not-move" bash-completion.sh,v to /etc/config-archive/foo and run dispatch-conf. It will "not-fail/fail" resp.
Comment 13 Ales Friedl 2009-02-24 09:44:14 UTC
It seems to be really simple.

dispatch-conf thinks that the new update is the same as the current bash-completion.sh. 

If you put something like "echo 'random text'" into the ._cfg000-bash-completion.sh file, it will be always merged fine.

dispatch-conf does know that the current bash-completion.sh was "downgraded" by "downgrade && upgrade" of bash-completion. It (probably) only looks into rcs archive, thinks that there is nothing to change, and does not check the current bash-completion.sh if it is really the same as it should be according to its rcs archive - ?

I do not know how this situation should be managed, probably dispatch-conf should say something if the current config file has been changed manually since last dispatch-conf run. Such change is what bc2009 actually does (mv bash-completion{,.sh}).
Comment 14 Ales Friedl 2009-02-24 10:09:27 UTC
I've found something in dispatch.conf:

# Ignore a version that is identical to the previously merged version,
# even though it is different from the current user modified version
# (yes or no)
ignore-previously-merged=yes

...which causes this behavior.

I do not remember if this is default, probably it is not, but if I've set this to yes, I supposed that "user modified version" means something which I do manually, not something which bc2009 does automatically in preinstall.

So there is probably nothing to fix, I only consider mv bash-completion{.sh} dangerous (in later stable bc).
Comment 15 Zac Medico gentoo-dev 2009-02-24 23:19:07 UTC
(In reply to comment #14)
> I've found something in dispatch.conf:
> 
> # Ignore a version that is identical to the previously merged version,
> # even though it is different from the current user modified version
> # (yes or no)
> ignore-previously-merged=yes
> 
> ...which causes this behavior.
> 
> I do not remember if this is default, probably it is not, but if I've set this
> to yes, I supposed that "user modified version" means something which I do
> manually, not something which bc2009 does automatically in preinstall.

It is enabled by default, but in future releases (changed in svn r12705) it will be disabled by default since emerge's already provides similar functionality which is a little safer (and can be disabled via --noconfmem).
Comment 16 Zac Medico gentoo-dev 2009-03-10 09:30:46 UTC
(In reply to comment #15)
> It is enabled by default, but in future releases (changed in svn r12705) it
> will be disabled by default since emerge's already provides similar
> functionality which is a little safer (and can be disabled via --noconfmem).

This is fixed in 2.2_rc24 which is in package.mask. It will also be released in 2.1.6.8 in about a week.