[gentoo-user] Re: This nite's switch to full multilib
Neil Bothwick neil at digimed.co.uk writes: I think we need to get away from solutions that clutter up configuration in the first place. I'm not under any illusions that this will ever be perfect, but I do think we can do better. Amen. Agreed, but this is about managing the options we have now. Like it or not, we need to put extra entries in package.use and eix-test-obsolete is the best current way of removing them when they're no longer needed, as portage's autounmask facility only adds to the file, it never cleans up after itself. And Amen, brother. As stated before, it reminds one of parenting where teenagers must take responsibility to clean up after themselves. GLEP 64 will go a long way to providing the framework for tool/code creation to clean up many, many errant files on gentoo. In fact if one were to desire building a system that is fully verified, you'd need something like GLEP-64 as the beginning or organization and tracking of what it's installed. Granted EAPI-5 is moving in the right direction, and it looks like we are moving to make that a requirement for all packages on gentoo. On my journey to learn more deeply about gentoo, I have looked closely at dozens and dozens of packages, maybe over 100. It is a freaking mess. Little consistency or structure or requirements from long ago, still have their remnants of effects. I find eix-test-obsolete (ETO) only produces valid things to address, at the lower end of the 20% mark. There is no way to 'tame the best' on it's sputum so I do not use it. The best ETO can do is suggest a list of things to look at (manually) for possible need of attention. If folks are really concerned about efficiency; it is quite easy to prune portage manually. I use scripts based on size or date, when I feel the need. Remove something important?: just --sync and download again; no worries. After all one can --sync to get something back if it is lost and of value. As I find attachment to codes that I want some permanency, I just replicate them into /usr/local/portage. I often like to keep old codes around (a very valid reason for 2T drives) to look at various codes and how they evolved. The various eclasses one package uses versus the eclasses chosen by another dev to package up a code. ETO thinks old codes and old kernels are cruft. I think the myriad of files spewed when some ebuilds are installed are cruft and they are often not accounted for when packages are removed. So let's all get behind GLEP-64 so folks can build some real tools for cleaning up and maintaining gentoo based systems. If you really want to get up on this issue, read up on Directed Graphs, particularly DAGs, and you'll begin to understand what is possible if GLEP-64 is *pushed* via the user base as a demand for those motivated devs to move us to a GLEP-64 compliant gentoo. Currently, unless you manually groom your gentoo system(s), you end up with a pig_sty as remnants of codes, installs, configs etc etc just pile up and it takes a one off inspection to filter many files as to should I stay or should I go now (old punk lyrics). It is way past time for gentoo to offer robust tools for monitoring and cleaning out cruft. What is cruft, needs to definable by the system owner. So the codes and tools will need to be flexible to fit the needs and desires of the user base, and therein we have much work to do, imho. hth, James
Re: [gentoo-user] Re: This nite's switch to full multilib
On Thu, 2 Apr 2015 07:21:01 +0200, Róbert Čerňanský wrote: Besides there is such database now - it is your (abused) package.use! You have to manually add entries to it and I do not know any database slower than human typing to a text file ;-) (There is autounmask option of course but then you allow portage to mess with your files which is not a good thing.) Portage doesn't change your package.use file, it creates a new one using the standard CONFIG_PROTECT process. Then you use etc-update or similar to view and verify the changes. -- Neil Bothwick Get your grubby hands off my tagline! I stole it first! pgpDeSIL5WgNX.pgp Description: OpenPGP digital signature
Re: [gentoo-user] Re: This nite's switch to full multilib
On Thu, 2 Apr 2015 09:41:10 +0100 Neil Bothwick n...@digimed.co.uk wrote: On Thu, 2 Apr 2015 07:21:01 +0200, Róbert Čerňanský wrote: Besides there is such database now - it is your (abused) package.use! You have to manually add entries to it and I do not know any database slower than human typing to a text file ;-) (There is autounmask option of course but then you allow portage to mess with your files which is not a good thing.) Portage doesn't change your package.use file, it creates a new one using the standard CONFIG_PROTECT process. Then you use etc-update or similar to view and verify the changes. What I am trying to tell is that portage manages its stuff (USE dependencies), through you, in your configuration files. It is nice that it does not overwrite them directly without asking ;-) but in the end the content ends up there one way or other. Portage should have its own internal database for USE deps and manage it like it manages db of standard package dependencies. Robert -- Róbert Čerňanský E-mail: ope...@tightmail.com Jabber: h...@jabber.sk
Re: [gentoo-user] Re: This nite's switch to full multilib
On Monday 30 March 2015 22:23:21 James wrote: package.use via automask is getting a bit out of hand, already. Somehow, I do not feel good about the devs solution is to munge up something I have already been abusing. So, does 'eix-test-obsolete' have some automated option to clean up package.use? I think I need to do this before applying the latest (dev_inspired) kludge to my main workstation? Someone mentioned enalyze, which I hadn't met before. Maybe that will help. -- Rgds Peter.
Re: [gentoo-user] Re: This nite's switch to full multilib
On Thu, Apr 2, 2015 at 12:42 AM, Sebastian Beßler sebast...@darkmetatron.de wrote: On 01.04.2015 19:28, Róbert Čerňanský wrote: Big advantage of automatic deps over --autounmask is that auto deps would not mess with user configuration files in /etc. Changed USE flags would be stored internally by portage. Ok, but then you need a database (another file in /etc/portage/) for all of the active use flags that are set by the installed packages. That or every emerge has to scan and parse every ebuild of all installed packages, adding a high delay. This is what portage already has to do with the list of installed packages. Doing it for installed USE flags is just more of the same. I suspect that portage has to do this anyway just to make sure that the current config is still valid, or to see if --newuse should cause a change, and so on. -- Rich
Re: [gentoo-user] Re: This nite's switch to full multilib
On Thu, 2 Apr 2015 11:29:33 +0200, Róbert Čerňanský wrote: Portage doesn't change your package.use file, it creates a new one using the standard CONFIG_PROTECT process. Then you use etc-update or similar to view and verify the changes. What I am trying to tell is that portage manages its stuff (USE dependencies), through you, in your configuration files. It is nice that it does not overwrite them directly without asking ;-) but in the end the content ends up there one way or other. Portage should have its own internal database for USE deps and manage it like it manages db of standard package dependencies. I'm coming round to that way of thinking too. I was simply pointing out that the autounmask feature doesn't clobber existing configs, so people weren't put off using it by the implication that it did. A mechanism for portage to manage this outside of /etc/portage would help separate portage's decisions and requirements from those of the user -- Neil Bothwick X-Modem- A device on the losing end of an encounter with lightning. pgpIRrltMCImj.pgp Description: OpenPGP digital signature
[gentoo-user] Re: This nite's switch to full multilib
On 2015-04-02, Róbert Čerňanský ope...@tightmail.com wrote: On Thu, 2 Apr 2015 09:41:10 +0100 Neil Bothwick n...@digimed.co.uk wrote: On Thu, 2 Apr 2015 07:21:01 +0200, Róbert Čerňanský wrote: Besides there is such database now - it is your (abused) package.use! You have to manually add entries to it and I do not know any database slower than human typing to a text file ;-) (There is autounmask option of course but then you allow portage to mess with your files which is not a good thing.) Portage doesn't change your package.use file, it creates a new one using the standard CONFIG_PROTECT process. Then you use etc-update or similar to view and verify the changes. What I am trying to tell is that portage manages its stuff (USE dependencies), through you, in your configuration files. It is nice that it does not overwrite them directly without asking ;-) but in the end the content ends up there one way or other. Portage should have its own internal database for USE deps and manage it like it manages db of standard package dependencies. I prefer it this way. I do not want all the nice easy-to read/edit configuration stuff in /etc/portage encrypted some Windows Registry break-alike. -- Grant Edwards grant.b.edwardsYow! Were these parsnips at CORRECTLY MARINATED in gmail.comTACO SAUCE?
Re: [gentoo-user] Re: This nite's switch to full multilib
On Thu, Apr 2, 2015 at 11:37 AM, Grant Edwards grant.b.edwa...@gmail.com wrote: I prefer it this way. I do not want all the nice easy-to read/edit configuration stuff in /etc/portage encrypted some Windows Registry break-alike. Nobody is proposing any changes to the format of package.use. The only proposal is that users shouldn't HAVE to specify every individual package use flag there if they just want the defaults. You do realize that this is EXACTLY how portage already behaves for installed packages, right? Portage keeps track of what is installed, and it doesn't go into the nice easy-to read/edit /var/lib/portage/world file. You tell portage what you want, and portage gives it to you. That is all that is being suggested here. If you want libxml2 built with USE=icu, go ahead and put that in /etc/portage/package.use. If you don't know what libxml2 is, or what icu is, then don't do anything and portage will install libxml2 with USE=icu if it needs to. The alternative is what I have now - a 1200 line package.keywords file that tells portage to build half the system 32-bit, when I could care less about all that stuff being 32-bit once I uninstall whatever package is making it that way, but portage will continue to build it all 32-bit because there is no in-between. -- Rich
Re: [gentoo-user] Re: This nite's switch to full multilib
On 01.04.2015 19:28, Róbert Čerňanský wrote: Big advantage of automatic deps over --autounmask is that auto deps would not mess with user configuration files in /etc. Changed USE flags would be stored internally by portage. Ok, but then you need a database (another file in /etc/portage/) for all of the active use flags that are set by the installed packages. That or every emerge has to scan and parse every ebuild of all installed packages, adding a high delay. The way as it is now is just fine, but always remember: With great power comes great responsibility Greetings Sebastian
Re: [gentoo-user] Re: This nite's switch to full multilib
On Thu, 02 Apr 2015 06:42:49 +0200 Sebastian Beßler sebast...@darkmetatron.de wrote: On 01.04.2015 19:28, Róbert Čerňanský wrote: Big advantage of automatic deps over --autounmask is that auto deps would not mess with user configuration files in /etc. Changed USE flags would be stored internally by portage. Ok, but then you need a database (another file in /etc/portage/) for all of the active use flags that are set by the installed packages. That or every emerge has to scan and parse every ebuild of all installed packages, adding a high delay. Of course you'll need a database (but not in /etc!). It might be /var/db/pkg or separate one, that is an implementation detail which I am not able to tell without knowledge of portage implementation. Besides there is such database now - it is your (abused) package.use! You have to manually add entries to it and I do not know any database slower than human typing to a text file ;-) (There is autounmask option of course but then you allow portage to mess with your files which is not a good thing.) Robert -- Róbert Čerňanský E-mail: ope...@tightmail.com Jabber: h...@jabber.sk
Re: [gentoo-user] Re: This nite's switch to full multilib
On 03/30/2015 02:52 PM, Grant Edwards wrote: I was also wondering if there might a way for emerge to show you which packages have USE flags enabled that aren't required by any dependent package: it would be sort of like emerge --depclean but for USE flags instead of packages themselves. Hi Grant, You are probably looking for enalyze from app-portage/gentookit. Presently it will rebuild your package.accept_keywords and package.use files after analyzing them. Its pretty darn helpful and only needs a little massaging after its done to be perfectly useful as a drop-in replacement file. Kind Regards, -Camisa
Re: [gentoo-user] Re: This nite's switch to full multilib
On Mon, 30 Mar 2015 13:14:55 +0200 Alan McKinnon alan.mckin...@gmail.com wrote: 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) ? [...] 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.* It depends what you see as a user choice. In my opinion by writing 'emerge skype' to the console the user clearly states his choice to install skype. If he actually cares what that would mean for his system he can use --pretend or --ask option together with --verbose and tweak USE flags if and only if he does not like it. So user has still full control over his system. 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 We could declare USE settings e.g. in make.conf as overridable by automatic USE dependencies so portage would not see it as incompatible. On the other hand package.use could be non-overridable thus allowing the user to have control over portage choices. 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 Big advantage of automatic deps over --autounmask is that auto deps would not mess with user configuration files in /etc. Changed USE flags would be stored internally by portage. Robert -- Róbert Čerňanský E-mail: ope...@tightmail.com Jabber: h...@jabber.sk
[gentoo-user] Re: This nite's switch to full multilib
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. 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. 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. 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. -h
Re: [gentoo-user] Re: This nite's switch to full multilib
On Mon, 30 Mar 2015 12:15:01 + (UTC), Holger Hoffstätte wrote: 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.* ..that just shows the root of the problem: the ABI is not handled consistently, but rather as a per-package configuration choice. The news item also showed how to make it a global choice, avoiding the need to multiple per-package directories. I already *collectively opted into* the 32-bit parallel universe by *choosing multilib*. All the current way is doing is repeating that choice without accomplishing anything, esp. since I cannot reasonably NOT make that choice. It's a hard requirement if I want to run a certain application. That's a fair point. Maybe multilib should default to ABI_X86=64 32 -- Neil Bothwick To the optimist, the glass is half full. To the pessimist, the glass is half empty. To the engineer, the glass is twice as big as it needs to be. pgptLoNXOUQgQ.pgp Description: OpenPGP digital signature
[gentoo-user] Re: This nite's switch to full multilib
On Mon, 30 Mar 2015 13:44:59 +0100, Neil Bothwick wrote: On Mon, 30 Mar 2015 12:15:01 + (UTC), Holger Hoffstätte wrote: 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.* ..that just shows the root of the problem: the ABI is not handled consistently, but rather as a per-package configuration choice. The news item also showed how to make it a global choice, avoiding the need to multiple per-package directories. I'm not sure that's a solution to the problem at all (which is why I didn't do it on my machines either). Apart from always wasting much more work resources than necessary for no good reason it doesn't answer the question what happens as soon as I want to build a package that is 64-bit-only - in which case you'd end up in the same situation we have now, just mirrored. -h
Re: [gentoo-user] Re: This nite's switch to full multilib
On Mon, 30 Mar 2015 13:04:47 + (UTC), Holger Hoffstätte wrote: The news item also showed how to make it a global choice, avoiding the need to multiple per-package directories. I'm not sure that's a solution to the problem at all (which is why I didn't do it on my machines either). Apart from always wasting much more work resources than necessary for no good reason it doesn't answer the question what happens as soon as I want to build a package that is 64-bit-only - in which case you'd end up in the same situation we have now, just mirrored. Yes, the only question is would it be a better or worse situation. From a pragmatic point of view it would be better, since the only inconvenience would be in extra builds, nothing would stop working in the meantime and you are far less likely to get blockers. Neither solution is ideal, but the change from the old binary packages had to be made at some point. At least we will now be spared the messages from revdep-rebuild and perl-cleaner about binary packages that won't change no matter how many time we reinstall them. -- Neil Bothwick Processor: (n.) a device for converting sense to nonsense at the speed of electricity, or (rarely) the reverse. pgp8bVa48CzFG.pgp Description: OpenPGP digital signature
Re: [gentoo-user] Re: This nite's switch to full multilib
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
[gentoo-user] Re: This nite's switch to full multilib
On Mon, 30 Mar 2015 13:14:55 +0200, Alan McKinnon wrote: On 30/03/2015 12:42, Holger Hoffstätte wrote: 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. That was my somewhat categorical way of saying that you'd be repeating yourself with no benefit. The ebuild already knows that it's 32-bit only, so making e.g. the user declare the same thing again would be wrong to begin with. I realize of course that's not how it is done, and that the abi constraint is a required part of the ebuild for precisely that reason. That the current transitional situation is a bit messy - fine. 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. That sounds great until you realize that selective capability configuration (aka USE flags, which I love and agree with!) is not the same as multilib profile selection. I really do understand the *idea* of strictly driving system capabilities from user-defined USE flags, so when you say: 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.* ..that just shows the root of the problem: the ABI is not handled consistently, but rather as a per-package configuration choice. I already *collectively opted into* the 32-bit parallel universe by *choosing multilib*. All the current way is doing is repeating that choice without accomplishing anything, esp. since I cannot reasonably NOT make that choice. It's a hard requirement if I want to run a certain application. It's great that Gentoo gives me choice, but I hope you can see how not having a certain capability or not runnig an application at all are two very different shoes. 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 No, they are complaining about the effects of the conflation of concepts, which ends up first in their config file (either manually or by portage), and eventually in their face, increasing the possibility of making completely unrelated mistakes later on. It also gives the false impression that this is a configuration choice, which it really isn't (see above). This also alludes to the secondary aspect I mentioned. Tightly coupling configuration choices possible in one world to the parallel world is going to be a real problem moving forward, precisely for the same reason: conflating a single mechanism for two different worlds with possibly different hard requirements. 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? Yes, *because I chose multilib*. That is *exactly* what I want, and - judging by some of the posts here and in the forums - also what most people seem to expect. I'm starting to wonder if it wouldn't be much more economical to provide prebuilt stacked layers of Docker images for 32-bit compatibility. That would solve several classes of problems at once, and not pollute the native Gentoo way with ultimately unsolvable problems. -h
Re: [gentoo-user] Re: This nite's switch to full multilib
On Monday 30 March 2015 15:34:55 Neil Bothwick wrote: At least we will now be spared the messages from [...] perl-cleaner about binary packages that won't change no matter how many time we reinstall them. That certainly is an improvement, yes. I was always unsure how safe I was in ignoring those messages. -- Rgds Peter.
Re: [gentoo-user] Re: This nite's switch to full multilib
On Mon, 30 Mar 2015 19:46:54 + (UTC), Grant Edwards wrote: The news item also showed how to make it a global choice, avoiding the need to multiple per-package directories. I'm not sure that's a solution to the problem at all (which is why I didn't do it on my machines either). If the problem is that you don't want things to be inconsistent, then it _does_ solve the problem. Apart from always wasting much more work resources than necessary for no good reason The reason is that somebody wanted their system to be consistent. I don't think that's a particulary good reason, but that's the nice thing aboug Gentoo. Everybody gets to decide what is important to them, and build their system accordingly. It's also practical as it requires no other changes to get your system working. However, it is even less efficient than I had envisaged. ABI_X86=64 32 emerge --update --deep --changed-use --with-bdeps y -pv @world gives Total: 237 packages (237 reinstalls), Whereas: grep -cv '^#' /etc/portage/package.use/abi_x86_32 gives 119 packages. So setting it globally would require three times as many packages to be rebuilt on this KDE system. -- Neil Bothwick You are a completely unique individual, just like everybody else. pgpsk8ddTNaMz.pgp Description: OpenPGP digital signature
[gentoo-user] Re: This nite's switch to full multilib
On 2015-03-30, Alan McKinnon alan.mckin...@gmail.com wrote: On 30/03/2015 15:04, Holger Hoffstätte wrote: On Mon, 30 Mar 2015 13:44:59 +0100, Neil Bothwick wrote: On Mon, 30 Mar 2015 12:15:01 + (UTC), Holger Hoffstätte wrote: 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.* ..that just shows the root of the problem: the ABI is not handled consistently, but rather as a per-package configuration choice. The news item also showed how to make it a global choice, avoiding the need to multiple per-package directories. I'm not sure that's a solution to the problem at all (which is why I didn't do it on my machines either). If the problem is that you don't want things to be inconsistent, then it _does_ solve the problem. Apart from always wasting much more work resources than necessary for no good reason The reason is that somebody wanted their system to be consistent. I don't think that's a particulary good reason, but that's the nice thing aboug Gentoo. Everybody gets to decide what is important to them, and build their system accordingly. it doesn't answer the question what happens as soon as I want to build a package that is 64-bit-only - in which case you'd end up in the same situation we have now, just mirrored. You can have your system be consistent by setting up everything using global values in make.conf, or you can choose to override that consistency by manually enabling/disabling USE variables on a per-package basis. That's how Gentoo works and how Gentoo has always worked. I don't how this is any different. Maybe it's time we asked the multilib devs how they intended to deal with these questions you raise. It seems there are two options: 1) Add abi_x86_32 on a package-by-package basis (or let emerge do it for you when you tell it to install something with 32-bit requirements like acroread). 2) Add ABI_X86=64 32 to make.conf, and then add -abi_x86_32 on a package-by-package basis if/when you want to build something 64-bit-only. It looks like they intended for you to choose whether you want 32 bit versions built as the exception or as the rule. For the former, you do 1). For the latter, you do 2). So far, I'm going with 1). When I decided to install acroread this morning, emerge added abi_x86_32 flags to package.use for about 80 packages. The other option would have re-built about 200 packages. Either way would have worked, but I wanted to see if emerge really was able to selectively rebuild the subset of packages required by acroread. AFAICT, it did just fine. -- Grant Edwards grant.b.edwardsYow! Yes, but will I at see the EASTER BUNNY in gmail.comskintight leather at an IRON MAIDEN concert?
Re: [gentoo-user] Re: This nite's switch to full multilib
On Monday, March 30, 2015 9:09:14 PM Alan McKinnon wrote: On 30/03/2015 15:04, Holger Hoffstätte wrote: On Mon, 30 Mar 2015 13:44:59 +0100, Neil Bothwick wrote: On Mon, 30 Mar 2015 12:15:01 + (UTC), Holger Hoffstätte wrote: 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.* ..that just shows the root of the problem: the ABI is not handled consistently, but rather as a per-package configuration choice. The news item also showed how to make it a global choice, avoiding the need to multiple per-package directories. I'm not sure that's a solution to the problem at all (which is why I didn't do it on my machines either). Apart from always wasting much more work resources than necessary for no good reason it doesn't answer the question what happens as soon as I want to build a package that is 64-bit-only - in which case you'd end up in the same situation we have now, just mirrored. Maybe it's time we asked the multilib devs how they intended to deal with these questions you raise. I don't have a problem with the way it is, but I think something like the following would be nice: instead of just supporting use_flag and -use_flag you could add something like @use_flag (auto-use flag) that automatically builds the feature only if needed to satisfy a dependency. That way you're not changing anything with existing configuration and still got full control over it. -- Fernando Rodriguez
[gentoo-user] Re: This nite's switch to full multilib
On 2015-03-30, Fernando Rodriguez frodriguez.develo...@outlook.com wrote: On Monday, March 30, 2015 9:09:14 PM Alan McKinnon wrote: Maybe it's time we asked the multilib devs how they intended to deal with these questions you raise. I don't have a problem with the way it is, but I think something like the following would be nice: instead of just supporting use_flag and -use_flag you could add something like @use_flag (auto-use flag) that automatically builds the feature only if needed to satisfy a dependency. That way you're not changing anything with existing configuration and still got full control over it. That could be pretty handy in cases like this. I was also wondering if there might a way for emerge to show you which packages have USE flags enabled that aren't required by any dependent package: it would be sort of like emerge --depclean but for USE flags instead of packages themselves. -- Grant Edwards grant.b.edwardsYow! The PILLSBURY DOUGHBOY at is CRYING for an END to gmail.comBURT REYNOLDS movies!!
Re: [gentoo-user] Re: This nite's switch to full multilib
On 30/03/2015 15:04, Holger Hoffstätte wrote: On Mon, 30 Mar 2015 13:44:59 +0100, Neil Bothwick wrote: On Mon, 30 Mar 2015 12:15:01 + (UTC), Holger Hoffstätte wrote: 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.* ..that just shows the root of the problem: the ABI is not handled consistently, but rather as a per-package configuration choice. The news item also showed how to make it a global choice, avoiding the need to multiple per-package directories. I'm not sure that's a solution to the problem at all (which is why I didn't do it on my machines either). Apart from always wasting much more work resources than necessary for no good reason it doesn't answer the question what happens as soon as I want to build a package that is 64-bit-only - in which case you'd end up in the same situation we have now, just mirrored. Maybe it's time we asked the multilib devs how they intended to deal with these questions you raise. -- Alan McKinnon alan.mckin...@gmail.com
[gentoo-user] Re: This nite's switch to full multilib
Peter Humphrey peter at prh.myzen.co.uk writes: On Sunday 29 March 2015 20:12:45 Alan McKinnon wrote: grep -ir qt /etc/portage grep qt /etc/portage/package.use | wc -l =11 dev-qt/qt-creator android autotools cmake python dev-qt/qtguiqt3support =dev-qt/qtsql-4.8.5 qt3support =dev-qt/qtcore-4.8.5-r1 qt3support # required by dev-qt/qtcore-4.8.5-r1[qt3support] =dev-qt/qtgui-4.8.5-r1 qt3support # required by dev-qt/qtopengl-4.8.5 =dev-qt/qtgui-4.8.5-r2 -qt3support # required by dev-qt/qt3support-4.8.5 =dev-qt/qtgui-4.8.5-r2 qt3support # required by dev-qt/qtwebkit-4.8.5[gstreamer] # grep -ir qt /etc/portage | wc -l =86 # eselect profile list Available profile symlink targets: [1] default/linux/amd64/13.0 * So I am multilib? How/where do I tell, as one reader posted that the profile is not where we designate if we are multilib or not (news to me). I am open to edumacation on this aspect. and help them remove all cruft that's getting in the way of a clean upgrade I just ran a 'depclean' a few days ago. Dozens of my java hacks (overlays) and such got cleaned out and my apache-spark ebuild (hack) does not compile anymore. No big deal, I get to spend another day learning all the neat things I do not know about maven.. I Did not even know a cleanup was needed but 'eix-test-obsolete' broke me down and kicked me in the teeth. I've got a lot to clean up: eix-test-obsolete | wc -l =209 emerge -uDNvp world | wc -l =111 emerge -uDNvp world : Total: 98 packages (2 upgrades, 2 new, 2 in new slots, 92 reinstalls, 3 uninstalls) All I have done so far is run emerge --sync. I previously sync'd up on 28mar2015 before that. I do not run KDE, I use lxde + lots of java (hacks) I refer to 'java(hacks)' because it is mostly a kludge of old portage packages and overlays. I have automask automated via make.conf. EMERGE_DEFAULT_OPTS=--with-bdeps y --autounmask-write y But before I follow the path of others: cat package.use | wc -l =314 package.use via automask is getting a bit out of hand, already. Somehow, I do not feel good about the devs solution is to munge up something I have already been abusing. So, does 'eix-test-obsolete' have some automated option to clean up package.use? I think I need to do this before applying the latest (dev_inspired) kludge to my main workstation? Maybe I should BE the chicken that I am, and wait a few days for others to flush this out a bit more? It's already been a hell(o)Monday for me.. On a brighter note, I do feel good that my instincts on kludging up a gentoo system, seem to be tracking the devs, quite nicely Guidance, humor and spankings are all welcome. James
[gentoo-user] Re: This nite's switch to full multilib
On 2015-03-30, Neil Bothwick n...@digimed.co.uk wrote: On Mon, 30 Mar 2015 19:46:54 + (UTC), Grant Edwards wrote: The reason is that somebody wanted their system to be consistent. I don't think that's a particulary good reason, but that's the nice thing aboug Gentoo. Everybody gets to decide what is important to them, and build their system accordingly. It's also practical as it requires no other changes to get your system working. However, it is even less efficient than I had envisaged. ABI_X86=64 32 emerge --update --deep --changed-use --with-bdeps y -pv @world gives Total: 237 packages (237 reinstalls), Whereas: grep -cv '^#' /etc/portage/package.use/abi_x86_32 gives 119 packages. So setting it globally would require three times as many packages to be rebuilt on this KDE system. That's roughly what I came up with this morning when I decided to try installing acroread on one of my XFCE boxes: 81 rebuilds one way, a handful over 200 the other. And I think it's at least the third time in the past few months I've looked up llvm to see what it is and why it's getting built -- I keep getting it confused with lvm. -- Grant Edwards grant.b.edwardsYow! Jesuit priests are at DATING CAREER DIPLOMATS!! gmail.com
[gentoo-user] Re: This nite's switch to full multilib
On 30/03/15 03:43, waben...@gmail.com wrote: Mick michaelkintz...@gmail.com wrote: On Sunday 29 Mar 2015 17:08:32 Yanestra wrote: On 03/29/2015 05:03 PM, waben...@gmail.com wrote: In most of the cases, Portage will be able to deliver correct suggestions for that when using the --autounmask feature. The first thing what happens here is that kde wants to upgrade because qtchooser's mask miraculously becomes ignored. And qtchooser itself doesn't install together with the libraries it pretends to control because there masses of conflicts, no matter what combination (qt4, qt5) I try. It has taken months of experimentation to get all the software to work which I need. It was tricky, because in many places only particular versions do. All that dissolves in a giant pile of rubbish... Regards, Yanestra I've also ended up with qt blockers, that I do not seem capable to overcome yet. KDE wants qt 4.8.5 installed which is blocking qt 4.8.6. How did you go about overcoming this? I also have dev-qt/qtcore-4.8.5-r2 and some other qt packages installed but I had no problems with that. I'm on gentoo stable (not ~amd64) and I don't use KDE. If you're on stable, you'll need to keyword qt-4.8.6 in its entirety. You can't mix and match versions, and 4.8.6 is the only one that supports multilib.
Re: [gentoo-user] Re: This nite's switch to full multilib
On 03/29/2015 07:27 PM, Michael Palimaka wrote: If you're on stable, you'll need to keyword qt-4.8.6 in its entirety. You can't mix and match versions, and 4.8.6 is the only one that supports multilib. Hm, a little documentation wouldn't hurt, don't you think? This guy has written a whole article about his trouble, and that was months ago...: https://lwn.net/Articles/605540/
Re: [gentoo-user] Re: This nite's switch to full multilib
(crossposting to -dev since this is fairly high-impact) On Sun, Mar 29, 2015 at 1:27 PM, Michael Palimaka kensing...@gentoo.org wrote: On 30/03/15 03:43, waben...@gmail.com wrote: I also have dev-qt/qtcore-4.8.5-r2 and some other qt packages installed but I had no problems with that. I'm on gentoo stable (not ~amd64) and I don't use KDE. If you're on stable, you'll need to keyword qt-4.8.6 in its entirety. You can't mix and match versions, and 4.8.6 is the only one that supports multilib. I think we really need to either stabilize 4.8.6, or backport qtchooser/multilib/etc to the current stable version. qt is a pretty significant package to have break with multilib, and trying to run qt-5 on a stable system is already a nightmare with the qtchooser switch (in my case I ended up abandoning qt5 as I didn't need it that badly). -- Rich
