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
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
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
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
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
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
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
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.
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/)
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
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.
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
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
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
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
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).
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
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
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
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).
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
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
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
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
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
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
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
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
(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
29 matches
Mail list logo
