| 1 |
On Mon, 30 Mar 2015 12:14:29 +0200, Alan McKinnon wrote: |
| 2 |
|
| 3 |
>> OK, then so why do I have to edit files to tell the system to USE this |
| 4 |
>> and that after the system tells me it needs that ... ? |
| 5 |
>> |
| 6 |
>> Why isn't this taken care of within portage itself? |
| 7 |
>> |
| 8 |
>> I don't *want* to decide 32bit or not ... (I like that I *can* ...) |
| 9 |
>> |
| 10 |
>> I want a (mostly) stable and current linux system with the necessary |
| 11 |
>> choices done by the maintainers ... if Skype needs it ... ok, then make |
| 12 |
>> that a dependency/requirement somewhere ... but why force me to set that |
| 13 |
>> (for so many packages) ? |
| 14 |
> |
| 15 |
> OK, think it through first. |
| 16 |
|
| 17 |
Sure thing. |
| 18 |
|
| 19 |
> You want skype. Skype is 32bit. So far, we're good. You put an entry in |
| 20 |
> package.use to enable abi_x86_32 for skype. |
| 21 |
|
| 22 |
Except..at that point you would have already failed. |
| 23 |
|
| 24 |
There is no good reason whatsoever why portage shouldn't be able to treat |
| 25 |
this like a transitive required USE flag requirement, percolating through |
| 26 |
all libs from the toplevel requirement's dependency tree. |
| 27 |
|
| 28 |
In fact it should do so automatically when the ebuild declares the abi_x86_32 |
| 29 |
constraint from the start, without requiring the user to do anything. |
| 30 |
|
| 31 |
There are other reasons why coupling the native and 32-bit worlds together is |
| 32 |
a bad idea in the long-term, regardless of understandable technical reasons |
| 33 |
and good intentions. |
| 34 |
|
| 35 |
So yeah: think it through first. |
| 36 |
|
| 37 |
-h |
Archives