1 |
On Mon, 2009-08-03 at 07:12 +0000, Duncan wrote: |
2 |
> Frank Peters <frank.peters@×××××××.net> posted |
3 |
> 20090803022804.b9e5a8a0.frank.peters@×××××××.net, excerpted below, on |
4 |
> Mon, 03 Aug 2009 02:28:04 -0400: |
5 |
> |
6 |
> > On Mon, 03 Aug 2009 01:21:40 -0500 |
7 |
> > Lance Lassetter <lancelassetter@×××××.com> wrote: |
8 |
> > |
9 |
> > |
10 |
> > |
11 |
> >> # bash --version |
12 |
> >> GNU bash, version 3.2.39(1)-release (x86_64-pc-linux-gnu) Copyright (C) |
13 |
> >> 2007 Free Software Foundation, Inc. |
14 |
> >> |
15 |
> >> |
16 |
> >> |
17 |
> > Thanks again. I thought so. My bash version is 4.0.28(2) and there |
18 |
> > obviously have been some changes. Version 3.2 goes back a long way. |
19 |
> > Another program where I have experienced problems is eselect, which is |
20 |
> > another bash script. Again there was a syntax fault. |
21 |
> > |
22 |
> > I will have to look into this a little better in the morning and maybe |
23 |
> > file a bug report. |
24 |
> |
25 |
> FWIW, here (and see below for the Gentoo versions): |
26 |
> |
27 |
> GNU bash, version 4.0.28(2)-release (x86_64-pc-linux-gnu) |
28 |
> |
29 |
> That's current ~amd64 as of yesterday's sync. |
30 |
> |
31 |
> I haven't run python-updater in some time but it ran fine when I ran it |
32 |
> last. I do need to run it again since python-3.1 was just in yesterday's |
33 |
> updates, tho, and see what happens. |
34 |
> |
35 |
> Meanwhile, I've had exactly zero problems with eselect, but I don't use |
36 |
> that many modules of it as I manage a lot of what it does, like the |
37 |
> kernel symlink, the make.profile symlink, etc, manually. |
38 |
> |
39 |
> Here's my bash, python and python-updater versions: |
40 |
> |
41 |
> $equery l bash python |
42 |
> * Searching for bash ... |
43 |
> [IP-] [ ~] app-shells/bash-4.0_p28 (0) |
44 |
> |
45 |
> * Searching for python ... |
46 |
> [IP-] [ ~] dev-lang/python-2.6.2-r1 (2.6) |
47 |
> [IP-] [ ~] dev-lang/python-3.1 (3.1) |
48 |
> |
49 |
> * Searching for python-updater ... |
50 |
> [IP-] [ ~] app-admin/python-updater-0.7 (0) |
51 |
> $ |
52 |
> |
53 |
> Are you full ~amd64, or did you package.keyword bash? If you're running |
54 |
> a mixed ~arch/stable system, it's possible that's the problem, tho it |
55 |
> doesn't look like it should be python-updater itself, since 0.7 is the |
56 |
> highest available for both stable and ~arch. |
57 |
> |
58 |
> Here's a depth-2 depends graph for the 4.0 p28 bash version: |
59 |
> |
60 |
> $equery g --depth=2 bash-4.0_p28 |
61 |
> * Searching for bash ... |
62 |
> * dependency graph for app-shells/bash-4.0_p28: |
63 |
> `-- app-shells/bash-4.0_p28 |
64 |
> `-- sys-libs/ncurses-5.7-r1 |
65 |
> `-- sys-libs/gpm-1.20.6 [gpm] |
66 |
> `-- sec-policy/selinux-gpm (unable to resolve: package masked or |
67 |
> removed) |
68 |
> `-- virtual/libintl-0 (virtual/libintl) [nls] |
69 |
> `-- sys-devel/gettext-0.17 [elibc_FreeBSD] |
70 |
> [ app-shells/bash-4.0_p28 stats: packages (5), max depth (2) ] |
71 |
> $ |
72 |
> |
73 |
> python-updater itself doesn't seem to have any significant dependencies, |
74 |
> just a package manager (portage, pkgcore or paludis), at the first level. |
75 |
> |
76 |
|
77 |
it's mixed. only select few packages installed ~x86 and their required |
78 |
deps. i would, personally, never go full blown ~x86 due to core |
79 |
packages needing to be stable. |