| View previous topic :: View next topic |
| Author |
Message |
are
Apprentice
Joined: 03 Jan 2006
Posts: 188
|
 Posted: Mon Sep 30, 2013 4:05 pm Post subject: |
 |
|
| mv wrote: | | are wrote: | | Do you ask me to manage a use.conf which lists all the libraries above with "ABI_X86: -* 32 64" explicitly set? |
Yes. Portage will help you to find out by its error message.
Alternatively, you can unset explicitly what you do not want. In my case, these are only a few packages. |
Sorry, but that can't be the solution. Remember, the use case is "pull required libs for pre-compiled 32-bit blobs". Beside Wine and Skype and perhaps Adobe Flash there is nothing.
We came from an excellent dependencies resolution, escaping Windows DLL-Hell and RPMs dependency chaos -- and now we start to manage dependency-list manually and are happy if the packager helps us with error messages?! 
Am I the only one who feels uncomfortable with that? |
|
| Back to top |
|
 |
mv
Watchman
Joined: 20 Apr 2005
Posts: 6747
|
| Posted: Mon Sep 30, 2013 7:48 pm Post subject: |
|
|
| are wrote: | | and now we start to manage dependency-list manually and are happy if the packager helps us with error messages?! :roll: |
You can also use --autounmask-write=y to let it portage write for you, but then you have to sort it by yourself.
If you want to minimize useflags there is nothing special about ABI_X86. You have the same advantages/disadvantages with every other useflag in the same way (some examples: static_libs, qt3support, accessibility, PYTHON_TARGET, ...) |
|
| Back to top |
|
|
are
Apprentice
Joined: 03 Jan 2006
Posts: 188
|
| Posted: Tue Oct 01, 2013 12:01 am Post subject: |
|
|
| mv wrote: | | If you want to minimize useflags there is nothing special about ABI_X86. You have the same advantages/disadvantages with every other useflag in the same way (some examples: static_libs, qt3support, accessibility, PYTHON_TARGET, ...) |
You describe exactly the problem, ABI_X86 is NOT like "every other" useflag. Same with PYTHON_TARGET/RUBY_TARGETs, but that is another story. In fact automatic dependency resolution is broken now. Either you manage long lists manually or you pull in loads of libs you do not need (when setting globally). Before it pulled the required EMULs only at least.
Do not get me wrong, I appreciate any replacement of the EMULs very much and do not want to have them back. But sacrificing proper dependency resolution lets me raise my eyebrows. |
|
| Back to top |
|
|
are
Apprentice
Joined: 03 Jan 2006
Posts: 188
|
| Posted: Tue Oct 01, 2013 2:11 am Post subject: |
|
|
I thought a little bit further and in my opinion we should implement tri-state useflags:
1) [-] for "switched off" explicitly
2) [+] for "requested" explicitly
and:
3) [&] for "allowed to pull" implicitly
Some of the use-flags like PYTHON_TARGETS, RUBY_TARGETS, ABI_X86 and static-libs should be able to apply and pull only in order to comply with dependencies.
Example: I would never explicitly set static-libs by myself. But some packages depend on it and enforce it. I would like to expect to "allow to pull" static-libs (e.g. setting &static-libs) and expect then the package manager to pull/recompile the NECESSARY libraries with static-libs allowed.
Does that make any sense please? |
|
| Back to top |
|
|
mv
Watchman
Joined: 20 Apr 2005
Posts: 6747
|
| Posted: Tue Oct 01, 2013 7:54 am Post subject: |
|
|
| are wrote: | | You describe exactly the problem, ABI_X86 is NOT like "every other" useflag. |
It is. It has exactly the problem of any other useflag which occurs in many pacakages as use-dependencies. I mentioned several more, and the list is by far not complete. |
|
| Back to top |
|
|
mv
Watchman
Joined: 20 Apr 2005
Posts: 6747
|
| Posted: Tue Oct 01, 2013 8:07 am Post subject: |
|
|
| are wrote: | | 3) [&] for "allowed to pull" implicitly. |
This is nonsense, because it would mean that a state of a package would depend on packages which depend on it. It woud mean portage could do only emerge -D @world and things like emerge -1O package would not be possible. Many years ago, there already was the concept of implicit USE-flags which automatically became activated when certain packages are emerged, and this concept has been dumped for good since such sort of smart-ass "I know better what you want than you" implicit dependencies are just plainly broken.
You deside whether you want a certain package as abi_x86_32 or as static; there is no problem with activating use-flags like abi_x86_32 or static globally. If you do not want this to save disk space and to get a minimal configuration you can optimize this manually. Similarly as you can optimize manually a "minimal" useflag if you want to eliminate things which most users get although only very few really need it: Getting such an optmiized system instead of a standard one just means some work. |
|
| Back to top |
|
|
Desti²
Tux's lil' helper
Joined: 06 Sep 2003
Posts: 127
|
|
| Back to top |
|
|
steveL
Watchman
Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery
|
| Posted: Wed Feb 05, 2014 6:34 am Post subject: |
|
|
| are wrote: | Example: I would never explicitly set static-libs by myself. But some packages depend on it and enforce it. I would like to expect to "allow to pull" static-libs (e.g. setting &static-libs) and expect then the package manager to pull/recompile the NECESSARY libraries with static-libs allowed.
Does that make any sense please? |
Not to me: it does that already; that's what dependency resolution means. As mv said, if you only want the flag to apply to certain packages, then it has to be set for those individually in package.use, given that it's off globally.
As to your wider point, again you were pointed at auto-unmasking; it's been a while since i needed it, but update does recursive unmasking in an automated fashion, which I think is what you're asking for. (Use it without autounmask-write, and let it react to the emerge messages; it'll show you a coloured diff before you commit to anything.) It sets required USE etc as well, though only works with single-file (not directory) package.use. |
|
| Back to top |
|
|
anyc
Tux's lil' helper
Joined: 31 May 2004
Posts: 119
|
| Posted: Sun Feb 16, 2014 10:51 am Post subject: |
|
|
| Desti² wrote: | | Has anyone a complete list of all packages required abi_x86_32 to run all Steam games? |
What do you mean exactly? There's a keywords file here that contains the packages I had to unlock for abi_x86_32 on my system. The complete list depends on your system but it may help as a starting point. |
|
| Back to top |
|
|
NP-Hardass
n00b
Joined: 24 Mar 2013
Posts: 36
|
| Posted: Fri Apr 03, 2015 9:08 pm Post subject: |
|
|
| xaviermiller wrote: | Hello,
I can emerge skype and wine (~amd64 multilib) with the "ABI_X86" feature (tested today, with the unmasked emul-blah-blah-r1 ebuild). |
I'd recommend trying to resolve the issue and removing emul-*. They are to be removed in the ~6 weeks, and I'm in the process of removing support for those emul-* in wine in the next couple of weeks to a month. |
|
| Back to top |
|
|
jonfr
Veteran
Joined: 20 Jul 2003
Posts: 1008
Location: Denmark
|
| Posted: Fri Apr 03, 2015 10:34 pm Post subject: |
|
|
I did add this line into /etc/portage/package.use .
Adding to make.conf did not work for me. Currently I am just waiting on all the packages to finish recompiling. |
|
| Back to top |
|
|
Tony0945
Watchman
Joined: 25 Jul 2006
Posts: 5127
Location: Illinois, USA
|
| Posted: Sat Apr 04, 2015 12:20 am Post subject: |
|
|
For those who want to use 32 bit for wine and nothing else use this file https://bpaste.net/show/88082d9ef16c which is an upload of wine.use on one of my systems. If /etc/portage/package.use is a directory, just add this file to the directory and reload the environment. To tell the truth, I always forget the magic words and just open a new terminal which also works.
If /etc/portage/package.use is a file, just concatenate this file to it. I have my files in directories to ease the masking of Gnome3.
This file will allow you to build wine with my use flags. One or two more may be required to your system. Wine is the biggie, requiring around 75 builds, autounmask-write should work fine for the others like adobe and ncurses. |
|
| Back to top |
|
|
Utsuho Reiuji
Apprentice
Joined: 03 Apr 2013
Posts: 179
|
| Posted: Sat Apr 04, 2015 1:21 pm Post subject: |
|
|
yay, finally another horror update...
| Code: | Total: 278 packages (55 upgrades, 2 new, 221 reinstalls), Size of downloads: 108,064 KiB
Conflict: 53 blocks (51 unsatisfied) |
guess I won't update for the next weeks :/ |
|
| Back to top |
|
|
Tony0945
Watchman
Joined: 25 Jul 2006
Posts: 5127
Location: Illinois, USA
|
| Posted: Sat Apr 04, 2015 7:58 pm Post subject: |
|
|
| Utsuho, you probably only needed about a third of those re-installs, unless you run a lot of 32-bit programs. I feel the advice in news item to enable 32 bit globally was wrong for most users. |
|
| Back to top |
|
|
Utsuho Reiuji
Apprentice
Joined: 03 Apr 2013
Posts: 179
|
| Posted: Sat Apr 04, 2015 9:14 pm Post subject: |
|
|
| Tony0945 wrote: | | Utsuho, you probably only needed about a third of those re-installs, unless you run a lot of 32-bit programs. I feel the advice in news item to enable 32 bit globally was wrong for most users. |
I would have to uninstall wine, too, as I am using it's WoW64 setup. If I understand the comments in this topic correctly, I could only run 32bit wine. |
|
| Back to top |
|
|
asturm
Developer
Joined: 05 Apr 2007
Posts: 8936
|
| Posted: Sat Apr 04, 2015 10:11 pm Post subject: |
|
|
What makes you think that?
| Tony0945 wrote: | | I feel the advice in news item to enable 32 bit globally was wrong for most users. |
I didn't read it so much as advice, rather a choice. Users should be able to judge for themselves. |
|
| Back to top |
|
|
Tony0945
Watchman
Joined: 25 Jul 2006
Posts: 5127
Location: Illinois, USA
|
| Posted: Sat Apr 04, 2015 11:25 pm Post subject: |
|
|
| Genstorm, users ARE given a choice. I read it as advice, followed it and found portage wanting to emerge 250+ packages when only 77 were required. There is no need to emerge 32bit on every package than is capable of it, only the ones that the user actually uses. |
|
| Back to top |
|
|
hasufell
Retired Dev
Joined: 29 Oct 2011
Posts: 429
|
| Posted: Sun Apr 05, 2015 10:12 am Post subject: |
|
|
| Tony0945 wrote: | | Genstorm, users ARE given a choice. I read it as advice, followed it and found portage wanting to emerge 250+ packages when only 77 were required. There is no need to emerge 32bit on every package than is capable of it, only the ones that the user actually uses. |
That'll leave you with figuring out dependency graphs by yourself pretty often.
It was a wrong choice to deprecate emul-linux packages, but devs don't care much about end users. They have some idea and like it and then they go for it, ignoring left and right voices. |
|
| Back to top |
|
|
NP-Hardass
n00b
Joined: 24 Mar 2013
Posts: 36
|
| Posted: Sun Apr 05, 2015 1:05 pm Post subject: |
|
|
| Utsuho Reiuji wrote: | | Tony0945 wrote: | | Utsuho, you probably only needed about a third of those re-installs, unless you run a lot of 32-bit programs. I feel the advice in news item to enable 32 bit globally was wrong for most users. |
I would have to uninstall wine, too, as I am using it's WoW64 setup. If I understand the comments in this topic correctly, I could only run 32bit wine. |
Not sure where that conclusion came from. Care to share? You should be able to mask the abi_x86_64 USE flag if you only wanted 32 bit wine, but what are you attempting to solve by doing that? I'm not sure that is the appropriate solution to your problem. |
|
| Back to top |
|
|
Tony0945
Watchman
Joined: 25 Jul 2006
Posts: 5127
Location: Illinois, USA
|
| Posted: Sun Apr 05, 2015 1:23 pm Post subject: |
|
|
hasufelll wrote: | Quote: |
It was a wrong choice to deprecate emul-linux packages, but devs don't care much about end users. They have some idea and like it and then they go for it, ignoring left and right voices. |
I totally agree. I was disputing the statement that 32bit had to be enabled globally, as suggested by the news item, forcing rebuilds on every (200-250) package having the capability.
I'm hoping that there will be minimal impact going forward. I am just trying to help users who have requested help on the forums. I wasted a day on this change and wanted to share what I had found. |
|
| Back to top |
|
|
Utsuho Reiuji
Apprentice
Joined: 03 Apr 2013
Posts: 179
|
| Posted: Sun Apr 05, 2015 4:52 pm Post subject: |
|
|
along with wine, I think this update could break steam  |
|
| Back to top |
|
|
VoidMage
Watchman
Joined: 14 Oct 2006
Posts: 6196
|
| Posted: Sun Apr 05, 2015 7:15 pm Post subject: |
|
|
| hasufell wrote: | | Tony0945 wrote: | | Genstorm, users ARE given a choice. I read it as advice, followed it and found portage wanting to emerge 250+ packages when only 77 were required. There is no need to emerge 32bit on every package than is capable of it, only the ones that the user actually uses. |
That'll leave you with figuring out dependency graphs by yourself pretty often.
It was a wrong choice to deprecate emul-linux packages, but devs don't care much about end users. They have some idea and like it and then they go for it, ignoring left and right voices. |
IIRC, the gentoo-dev mail archives show that it was a choice between a somewhat dirty hack, that nevertheless could be achieved within existing EAPI and making some never-clearly-stated additions/changes to EAPI and PMS. For all the stomach churning beauty of multilib ebuilds, they work right now. |
|
| Back to top |
|
|
hasufell
Retired Dev
Joined: 29 Oct 2011
Posts: 429
|
| Posted: Sun Apr 05, 2015 9:03 pm Post subject: |
|
|
| VoidMage wrote: | | hasufell wrote: | | Tony0945 wrote: | | Genstorm, users ARE given a choice. I read it as advice, followed it and found portage wanting to emerge 250+ packages when only 77 were required. There is no need to emerge 32bit on every package than is capable of it, only the ones that the user actually uses. |
That'll leave you with figuring out dependency graphs by yourself pretty often.
It was a wrong choice to deprecate emul-linux packages, but devs don't care much about end users. They have some idea and like it and then they go for it, ignoring left and right voices. |
IIRC, the gentoo-dev mail archives show that it was a choice between a somewhat dirty hack, that nevertheless could be achieved within existing EAPI and making some never-clearly-stated additions/changes to EAPI and PMS. For all the stomach churning beauty of multilib ebuilds, they work right now. |
I was around IRC when it went down. It was a bit different and basically a failure of the council to resolve a global issue or step in when needed.
It was ended by the dull sentence "any1 can add an eclass to the tree". It wasn't really a decision. It just "happened". And then at some point people stopped thinking about it.
When the emul-linux team was asked to share their scripts/knowledge about packaging emul-linux packages, they refused to which is basically against our social contract. Otherwise, we'd probably have an overlay for it now. |
|
| Back to top |
|
|
evadim
n00b
Joined: 24 Dec 2006
Posts: 5
Location: Russia
|
| Posted: Sun Apr 05, 2015 10:53 pm Post subject: |
|
|
Hello all,
I look to topic briefly and didn't see answer.
I wan't to share thing, which is really solve giant list of blocked qt packages.
really, 200 for me is not solve locks.
I have only Skype installed. |
|
| Back to top |
|
|
Havin_it
Veteran
Joined: 17 Jul 2005
Posts: 1247
Location: Edinburgh, UK
|
| Posted: Thu Apr 30, 2015 2:37 pm Post subject: |
|
|
| I hope a slight threadjack is permitted, it seems germane: Currently gcc[multilib] still depends on emul-linux-x86-* packages. I haven't seen any mention of this, is there a simple fix for it that I'm missing? |
|
| Back to top |
|
|
|
Portage & Programming
