On 30/03/2015 12:42, Holger Hoffstätte wrote: > On Mon, 30 Mar 2015 12:14:29 +0200, Alan McKinnon wrote: > >>> OK, then so why do I have to edit files to tell the system to USE this >>> and that after the system tells me it needs that ... ? >>> >>> Why isn't this taken care of within portage itself? >>> >>> I don't *want* to decide 32bit or not ... (I like that I *can* ...) >>> >>> I want a (mostly) stable and current linux system with the necessary >>> choices done by the maintainers ... if Skype needs it ... ok, then make >>> that a dependency/requirement somewhere ... but why force me to set that >>> (for so many packages) ? >> >> OK, think it through first. > > Sure thing. > >> You want skype. Skype is 32bit. So far, we're good. You put an entry in >> package.use to enable abi_x86_32 for skype. > > Except..at that point you would have already failed.
That does not compute. Please explain. > > There is no good reason whatsoever why portage shouldn't be able to treat > this like a transitive required USE flag requirement, percolating through > all libs from the toplevel requirement's dependency tree. Correct, there is no good reason why portage *can't* do that. There is a very good reason why portage *won't* do that, it is not the gentoo way and it goes against gentoo's social contract. Portage does not override your choices, and it certainly does not allow one single ebuild to automagically change the behaviour of multiple other ebuilds. The correct way to bring about changes in behaviour is to add your global choices to make.conf (which is outside the control of the tree), or to add your explicit changes to package.* Portage's default behaviour when confronted with incompatible settings has always been to detect them, and print the output to the console telling you what to do. Now, there is a helper function that you as the system owner can enable if you trust portage and the tree to always make the correct decision - autounmask. You can run it with -p to get a full list that you can edit before running it for real, or you can just let portage go ahead and make the changes it feels are correct. But this is not default behaviour and for very good reason. I get the sense that those who are complaining about abi_x86_32 in this thread are mostly not complaining about what portage does, they are complaining about the number of entries they have to make to portage.use I don't understand why you are advocating a dramatic change in portage's behaviour from what it has done for years. Yes, this latest feature does require some work from you. You have been doing this same work for ages, the main difference being that this time it's a large amount of once-off work. > > In fact it should do so automatically when the ebuild declares the abi_x86_32 > constraint from the start, without requiring the user to do anything. So you want a single ebuild to trigger a tree-wide change in behaviour? I don't think that's a good idea > > There are other reasons why coupling the native and 32-bit worlds together is > a bad idea in the long-term, regardless of understandable technical reasons > and good intentions. > > So yeah: think it through first. I already did. Refer this post. I think I thought about it in ways that you have not considered yet. -- Alan McKinnon alan.mckin...@gmail.com
