| 1 |
>>why should everybody have libstdc++-v3 installed? just some ebuilds that |
| 2 |
>>install pre-compiled software will depend on specific libstdc++ versions. |
| 3 |
> |
| 4 |
> if you make me a comprehensive list of every binary c++ app/plugin in the |
| 5 |
> portage tree linked against the old libstdc++, i'll update their |
| 6 |
> dependencies. however, i dont assume anyone maintaining an app will |
| 7 |
> automatically realise that this dependency is needed if using gcc 3.4... and |
| 8 |
> there are a -lot- of ebuilds that would need updating, most of which arent |
| 9 |
> even supported on my arch (so i cant test and dont want to touch them |
| 10 |
> myself). perhaps spanky's idea of just slamming another binary into |
| 11 |
> lib-compat is a good one... |
| 12 |
|
| 13 |
So which ebuild will depend on lib-compat than? there's no list of that |
| 14 |
ebuilds, that's true, but just because there has been mistakes in the |
| 15 |
past, you shouldn't block improvements. |
| 16 |
|
| 17 |
You should perhaps intruduce those virtuals now, and remove the |
| 18 |
workarounds later, when most of the ebuilds are using these virtuals. |
| 19 |
|
| 20 |
>>there also another point: somebody having gcc-3.2 or gcc-3.3 installed |
| 21 |
>>doesn't need libstdc++-v3 too, and the gentoo-way of solving that is to |
| 22 |
>>use virtuals. |
| 23 |
> |
| 24 |
> true. but using profiles is a useful solution until we can get to -every- |
| 25 |
> binary in the tree. :) |
| 26 |
|
| 27 |
Sure, i don't want anybody to change every ebuild until tomorrow, but i |
| 28 |
think i discovered a m drawback which need to be handled better. |
| 29 |
|
| 30 |
In addition, every C++ application in a system depends on some version |
| 31 |
of the libstdc++. The portage could even take care of that by |
| 32 |
determining which version of libstdc++ is used by the compiled binaries |
| 33 |
and adding a depency to the portage-database. |
| 34 |
|
| 35 |
|
| 36 |
-- |
| 37 |
gentoo-dev@g.o mailing list |
Archives