Re: [gentoo-dev] Portage dependency solving algorithm

2014-11-08 Thread Andrew Savchenko
On Sat, 8 Nov 2014 13:35:20 + Ciaran McCreesh wrote: > On Sat, 8 Nov 2014 13:56:21 +0300 > Andrew Savchenko wrote: > > Wanna ~20-30 minutes with sqlite metadata cache enabled? > > Try on Intel Atom N270 with 2800 packages installed. > > Dependency resolution is utterly slow. > > Well I highly

Re: [gentoo-dev] Portage dependency solving algorithm

2014-11-08 Thread Andrew Savchenko
On Sat, 08 Nov 2014 15:45:30 -0800 Zac Medico wrote: > On 11/08/2014 03:33 PM, Patrick Lauer wrote: > > We can choose for "code that works reasonably fast" - portage hasn't > > gotten any noticeable work on performance in a while, and people have > > just piled on more and more features and complex

Re: [gentoo-dev] Portage dependency solving algorithm

2014-11-08 Thread hasufell
On 11/09/2014 01:08 AM, Patrick Lauer wrote: > On 11/09/2014 08:04 AM, hasufell wrote: >> On 11/09/2014 12:33 AM, Patrick Lauer wrote: >>> It's not about NIH, it's about slow code being slow. >>> >> >> Can't disagree more. It's about wrong results, broken systems, >> unreadable error messages, days

Re: [gentoo-dev] Portage dependency solving algorithm

2014-11-08 Thread Patrick Lauer
On 11/09/2014 08:04 AM, hasufell wrote: > On 11/09/2014 12:33 AM, Patrick Lauer wrote: >> It's not about NIH, it's about slow code being slow. >> > > Can't disagree more. It's about wrong results, broken systems, > unreadable error messages, days of figuring out ruby, perl, haskell, > multilib, py

Re: [gentoo-dev] Portage dependency solving algorithm

2014-11-08 Thread hasufell
On 11/09/2014 12:33 AM, Patrick Lauer wrote: > It's not about NIH, it's about slow code being slow. > Can't disagree more. It's about wrong results, broken systems, unreadable error messages, days of figuring out ruby, perl, haskell, multilib, python blockers, incorrect autounmask suggestions and

Re: [gentoo-dev] Portage dependency solving algorithm

2014-11-08 Thread Zac Medico
On 11/08/2014 03:52 PM, hasufell wrote: > On 11/08/2014 11:39 PM, Zac Medico wrote: >> On 11/08/2014 02:05 PM, hasufell wrote: >>> I have a feeling that this is an assumption as well. PMS just says this >>> is an 'any-of' group. There is not a single word about the processing >>> order of these spe

Re: [gentoo-dev] Portage dependency solving algorithm

2014-11-08 Thread hasufell
On 11/08/2014 11:39 PM, Zac Medico wrote: > On 11/08/2014 02:05 PM, hasufell wrote: >> I have a feeling that this is an assumption as well. PMS just says this >> is an 'any-of' group. There is not a single word about the processing >> order of these specs or which one to prefer, in which case some

Re: [gentoo-dev] REQUIRED_USE="test" vs. repoman

2014-11-08 Thread Kent Fredric
On 9 November 2014 09:06, Zac Medico wrote: > Since EAPI 5, you need to either add test to IUSE, or else we need to > add the test flag to IUSE_IMPLICIT in the base profile (that would > require some discussion of pros/cons). > It should have been needed on EAPI4 too, but due to a side effect of

Re: [gentoo-dev] Portage dependency solving algorithm

2014-11-08 Thread Zac Medico
On 11/08/2014 03:33 PM, Patrick Lauer wrote: > We can choose for "code that works reasonably fast" - portage hasn't > gotten any noticeable work on performance in a while, and people have > just piled on more and more features and complexity. Yes, as one of only 2 people who have worked on the res

Re: [gentoo-dev] Portage dependency solving algorithm

2014-11-08 Thread Patrick Lauer
On 11/08/2014 10:48 PM, hasufell wrote: > On 11/08/2014 02:24 PM, Patrick Lauer wrote: >> On 11/08/2014 03:08 AM, hasufell wrote: >>> On 11/07/2014 07:54 PM, Matthias Maier wrote: > Well, you're not comparing like with like. Paludis with "everything > turned off" does more than Portage with

Re: [gentoo-dev] Portage dependency solving algorithm

2014-11-08 Thread Zac Medico
On 11/08/2014 02:05 PM, hasufell wrote: > On 11/08/2014 10:52 PM, Jauhien Piatlicki wrote: >> 08.11.14 22:47, hasufell написав(ла): >>> On 11/08/2014 10:30 PM, Rich Freeman wrote: On Sat, Nov 8, 2014 at 2:48 PM, hasufell wrote: > On 11/08/2014 08:32 PM, hasufell wrote: >>> Sorry to ch

Re: [gentoo-dev] Portage dependency solving algorithm

2014-11-08 Thread hasufell
On 11/08/2014 10:52 PM, Jauhien Piatlicki wrote: > 08.11.14 22:47, hasufell написав(ла): >> On 11/08/2014 10:30 PM, Rich Freeman wrote: >>> On Sat, Nov 8, 2014 at 2:48 PM, hasufell wrote: On 11/08/2014 08:32 PM, hasufell wrote: >> Sorry to chime in like that but if you don't mind, I'd lik

Re: [gentoo-dev] Portage dependency solving algorithm

2014-11-08 Thread Jauhien Piatlicki
08.11.14 22:47, hasufell написав(ла): > On 11/08/2014 10:30 PM, Rich Freeman wrote: >> On Sat, Nov 8, 2014 at 2:48 PM, hasufell wrote: >>> On 11/08/2014 08:32 PM, hasufell wrote: > Sorry to chime in like that but if you don't mind, I'd like to ask for a > real-life example for badly declar

Re: [gentoo-dev] Portage dependency solving algorithm

2014-11-08 Thread hasufell
On 11/08/2014 10:30 PM, Rich Freeman wrote: > On Sat, Nov 8, 2014 at 2:48 PM, hasufell wrote: >> On 11/08/2014 08:32 PM, hasufell wrote: >>> On 11/08/2014 08:01 PM, Matthias Dahl wrote: Hello Ciaran... On 08/11/14 19:26, Ciaran McCreesh wrote: > No. It would make sense to i

Re: [gentoo-dev] REQUIRED_USE="test" vs. repoman

2014-11-08 Thread Jeroen Roovers
On Sat, 08 Nov 2014 20:49:10 +0100 Thomas Kahle wrote: > However, repoman complains: > > REQUIRED_USE.syntax 1 >media-libs/leptonica/leptonica-1.71-r1.ebuild: REQUIRED_USE: USE > flag 'test' is not in IUSE > > I commited with -f, because I think repoman is wrong. Any opinions?

Re: [gentoo-dev] REQUIRED_USE="test" vs. repoman

2014-11-08 Thread Michał Górny
Dnia 2014-11-08, o godz. 20:49:10 Thomas Kahle napisał(a): > Hi, > > it seems to be a quasi-standard in the tree to use REQUIRED_USE > if the tests of some package need USE flags. However, repoman > complains: > > REQUIRED_USE.syntax 1 >media-libs/leptonica/leptonica-1.71-r1.eb

Re: [gentoo-dev] Portage dependency solving algorithm

2014-11-08 Thread Rich Freeman
On Sat, Nov 8, 2014 at 2:48 PM, hasufell wrote: > On 11/08/2014 08:32 PM, hasufell wrote: >> On 11/08/2014 08:01 PM, Matthias Dahl wrote: >>> Hello Ciaran... >>> >>> On 08/11/14 19:26, Ciaran McCreesh wrote: >>> No. It would make sense to introduce a cultural change, where developers sto

[gentoo-dev] Re: Portage dependency solving algorithm

2014-11-08 Thread Duncan
Andrew Savchenko posted on Sat, 08 Nov 2014 13:56:21 +0300 as excerpted: > Wanna ~20-30 minutes with sqlite metadata cache enabled? > Try on Intel Atom N270 with 2800 packages installed. Dependency > resolution is utterly slow. Hmm. My netbook's an Atom N270 also. But I use a build-image chroot

Re: [gentoo-dev] REQUIRED_USE="test" vs. repoman

2014-11-08 Thread Zac Medico
On 11/08/2014 11:49 AM, Thomas Kahle wrote: > Hi, > > it seems to be a quasi-standard in the tree to use REQUIRED_USE > if the tests of some package need USE flags. However, repoman > complains: > > REQUIRED_USE.syntax 1 >media-libs/leptonica/leptonica-1.71-r1.ebuild: REQUIRED_US

[gentoo-dev] REQUIRED_USE="test" vs. repoman

2014-11-08 Thread Thomas Kahle
Hi, it seems to be a quasi-standard in the tree to use REQUIRED_USE if the tests of some package need USE flags. However, repoman complains: REQUIRED_USE.syntax 1 media-libs/leptonica/leptonica-1.71-r1.ebuild: REQUIRED_USE: USE flag 'test' is not in IUSE I commited with -f, becau

Re: [gentoo-dev] Portage dependency solving algorithm

2014-11-08 Thread hasufell
On 11/08/2014 08:32 PM, hasufell wrote: > On 11/08/2014 08:01 PM, Matthias Dahl wrote: >> Hello Ciaran... >> >> On 08/11/14 19:26, Ciaran McCreesh wrote: >> >>> No. It would make sense to introduce a cultural change, where >>> developers stop writing dependencies that seem to work with some >>> par

Re: [gentoo-dev] Portage dependency solving algorithm

2014-11-08 Thread hasufell
On 11/08/2014 08:01 PM, Matthias Dahl wrote: > Hello Ciaran... > > On 08/11/14 19:26, Ciaran McCreesh wrote: > >> No. It would make sense to introduce a cultural change, where >> developers stop writing dependencies that seem to work with some >> particular version of Portage if you don't look ve

Re: [gentoo-dev] Portage dependency solving algorithm

2014-11-08 Thread Matthias Dahl
Hello Ciaran... On 08/11/14 19:26, Ciaran McCreesh wrote: > No. It would make sense to introduce a cultural change, where > developers stop writing dependencies that seem to work with some > particular version of Portage if you don't look very closely, and start > writing good dependencies. Sorr

Re: [gentoo-dev] Portage dependency solving algorithm

2014-11-08 Thread Ciaran McCreesh
On Sat, 8 Nov 2014 10:11:13 -0800 Hilco Wijbenga wrote: > So would it make sense then to move to a more declarative ebuild > model? Or just a "better" model? No. It would make sense to introduce a cultural change, where developers stop writing dependencies that seem to work with some particular v

Re: [gentoo-dev] Portage dependency solving algorithm

2014-11-08 Thread Hilco Wijbenga
On 8 November 2014 05:40, Ciaran McCreesh wrote: > On Fri, 07 Nov 2014 20:57:41 +0100 > Jauhien Piatlicki wrote: >> What;s wrong with input? PMS itself or how do maintainers write >> ebuilds? Could you explain? > > A mixture of both. Gentoo developers like writing eclasses that write > unnecessar

Re: [gentoo-dev] fixed my virt-manager issue; libvirt-python-9999.ebuild

2014-11-08 Thread Matthias Maier
I've commited a live ebuild for libvirt-python to CVS. Given the fact that we already have one for libvirt and one for virt-manager, this makes sense. Best, Matthias *libvirt-python- (08 Nov 2014) 08 Nov 2014; Matthias Maier +libvirt-python-.ebuild: provide live ebuild as suggested

Re: [gentoo-dev] Portage dependency solving algorithm

2014-11-08 Thread hasufell
On 11/08/2014 02:24 PM, Patrick Lauer wrote: > On 11/08/2014 03:08 AM, hasufell wrote: >> On 11/07/2014 07:54 PM, Matthias Maier wrote: Well, you're not comparing like with like. Paludis with "everything turned off" does more than Portage with "everything turned on". If all you're lo

Re: [gentoo-dev] Portage dependency solving algorithm

2014-11-08 Thread viv...@gmail.com
Il 08/11/2014 14:35, Ciaran McCreesh ha scritto: > On Sat, 08 Nov 2014 09:29:52 +0100 > "viv...@gmail.com" wrote: >> "The time dependency resolving takes is marginal compared to the whole >> update process " >> ^^^ this is an utter lie for frequent updates > Uh, how long are your resolves taking?

Re: [gentoo-dev] Last rites: razorqt-base/*

2014-11-08 Thread Ben de Groot
On 8 November 2014 19:15, Jauhien Piatlicki wrote: > Hi Ben, > > Have you read comments on Qt overlay commit? Have you check reverse > dependencies of packages you are masking? razorqt-base/libqtxdg is used by > LXQt. So, please, unmask it. I will move it into lxqt-base category. But > until th

Re: [gentoo-dev] Portage dependency solving algorithm

2014-11-08 Thread Ciaran McCreesh
On Fri, 07 Nov 2014 22:04:57 +0100 hasufell wrote: > Next thing that comes to my mind is: indeterministic results. I'v had > LOTS of them with portage. You run an emerge, abort. You run it > again... and woosh, different result. > I'v not hit that case yet with paludis, unless I ran it with differ

Re: [gentoo-dev] Portage dependency solving algorithm

2014-11-08 Thread Ciaran McCreesh
On Fri, 07 Nov 2014 20:57:41 +0100 Jauhien Piatlicki wrote: > What;s wrong with input? PMS itself or how do maintainers write > ebuilds? Could you explain? A mixture of both. Gentoo developers like writing eclasses that write unnecessarily clever, highly messy and technically incorrect dependency

Re: [gentoo-dev] Portage dependency solving algorithm

2014-11-08 Thread Ciaran McCreesh
On Sat, 08 Nov 2014 09:29:52 +0100 "viv...@gmail.com" wrote: > "The time dependency resolving takes is marginal compared to the whole > update process " > ^^^ this is an utter lie for frequent updates Uh, how long are your resolves taking? -- Ciaran McCreesh signature.asc Description: PGP sig

Re: [gentoo-dev] Portage dependency solving algorithm

2014-11-08 Thread Patrick Lauer
On 11/08/2014 03:08 AM, hasufell wrote: > On 11/07/2014 07:54 PM, Matthias Maier wrote: >>> Well, you're not comparing like with like. Paludis with "everything >>> turned off" does more than Portage with "everything turned on". If all >>> you're looking for is the wrong answer as fast as possible,

Re: [gentoo-dev] Last rites: razorqt-base/*

2014-11-08 Thread Jauhien Piatlicki
I see it was unmasked back already. Thanks. -- Jauhien 08.11.14 12:15, Jauhien Piatlicki написав(ла): > Hi Ben, > > Have you read comments on Qt overlay commit? Have you check reverse > dependencies of packages you are masking? razorqt-base/libqtxdg is used by > LXQt. So, please, unmask it. I

Re: [gentoo-dev] Last rites: razorqt-base/*

2014-11-08 Thread Jauhien Piatlicki
Hi Ben, Have you read comments on Qt overlay commit? Have you check reverse dependencies of packages you are masking? razorqt-base/libqtxdg is used by LXQt. So, please, unmask it. I will move it into lxqt-base category. But until this, please, do not touch it. And, please, make sure you are rea

Re: [gentoo-dev] Portage dependency solving algorithm

2014-11-08 Thread Andrew Savchenko
On Fri, 07 Nov 2014 20:08:12 +0100 hasufell wrote: > On 11/07/2014 07:54 PM, Matthias Maier wrote: > >> Well, you're not comparing like with like. Paludis with "everything > >> turned off" does more than Portage with "everything turned on". If all > >> you're looking for is the wrong answer as fast

Re: [gentoo-dev] Portage dependency solving algorithm

2014-11-08 Thread Andrew Savchenko
On Fri, 7 Nov 2014 19:21:01 + Ciaran McCreesh wrote: > On Fri, 07 Nov 2014 19:54:08 +0100 > Matthias Maier wrote: > > Currently, for portage just to decide that nothing has to be done on > > my machine takes around 1 minute. > > Are you running with or without metadata cache? If you're runnin

Re: [gentoo-dev] Portage dependency solving algorithm

2014-11-08 Thread viv...@gmail.com
Il 07/11/2014 20:08, hasufell ha scritto: > Also, I don't understand these discussions. The time dependency > resolving takes is marginal compared to the whole update process, no > matter what PM you use. "The time dependency resolving takes is marginal compared to the whole update process " ^^^ th