From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by finch.gentoo.org (Postfix) with ESMTPS id 57023138350 for ; Thu, 23 Apr 2020 23:55:34 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 3E458E0BFA; Thu, 23 Apr 2020 23:55:27 +0000 (UTC) Received: from mail-40132.protonmail.ch (mail-40132.protonmail.ch [185.70.40.132]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 60337E0AAE for ; Thu, 23 Apr 2020 23:55:26 +0000 (UTC) Date: Thu, 23 Apr 2020 23:55:13 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail; t=1587686124; bh=wtQq5SPprNqnP0vVg+2WIBgMnBKW3pGduJGvttwqpQQ=; h=Date:To:From:Reply-To:Subject:In-Reply-To:References:From; b=MrbsSQXNjEAlgAl1O6vJaPeDo5dpvTKD4N4atrxKd1YrDJuze2iIB9oz/sPq/O7nb zx0AtuGJ4nzKcbrDcx9Y3D0TTE8LgcackQDf33WghvCLOKwCAzByHt4g+dZvfcTDLP G0oXg8dVxryStlJ0oR7insf7ovc16+Kt3tTZo3j8= To: "gentoo-user@lists.gentoo.org" From: Caveman Al Toraboran Subject: Re: [gentoo-user] Is Gentoo dead? Message-ID: In-Reply-To: <46ece385-9e6f-4416-a071-98eebb9dc8f2@www.fastmail.com> References: <20200421165803.GB187193@redacted> <11506562.O9o76ZdvQC@peak> <20200421190145.GF187193@redacted> <0d270fdf-1de2-03b4-1f5a-702450975561@gmail.com> <2b6a7f82-b4c2-2115-e4e5-2ec27482a4c9@gentoo.org> <46ece385-9e6f-4416-a071-98eebb9dc8f2@www.fastmail.com> Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-user@lists.gentoo.org Reply-to: gentoo-user@lists.gentoo.org X-Auto-Response-Suppress: DR, RN, NRN, OOF, AutoReply MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-1.2 required=7.0 tests=ALL_TRUSTED,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM shortcircuit=no autolearn=disabled version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on mail.protonmail.ch X-Archives-Salt: 10278271-01a4-493c-ad1e-40a2b546f4b9 X-Archives-Hash: 062ed5ddd3718511effaf9b04482808e On Friday, April 24, 2020 1:03 AM, Alec Ten Harmsel wrote: > If it's so easy, why don't you implement it? /s because busy and got better things in life. but what is your point? 1. are you trying to get to know me a bit closer? 2. or are you trying to indirectly a claim that making portage faster is too hard? if (1) then off-topic. if (2) then you're committing a logical fallacy. some version of appeal to majority? hence your claim is unsubstantiated, and is deleted from space thanks to occam's razor. if it was too hard for most people in the past, it doesn't mean that it is hard for everyone else. not saying that your claim is wrong. but saying that your tool to show that claim is not working. not saying that your claim is right either. it's so far floating somewhere in the ``unknown'' region (until a proof is presented; not a logical fallacy). > Sorry for being a little glib but every couple months I go through this t= hought process: > > 1. Wow, portage is slow > 2. I can make this faster, it can't be that hard > 3. ...wow, nevermind, it is really hard > 4. Thank you portage maintainers!!!!! if your point is to share history, thanks. else: logical fallacy (read above). > I don't think it's O(log n). Roughly, for 1 package portage has to make t= he full dep > tree, solve all the constraints to resolve to actual packages that can be= installed, > and order and merge the tree into a single branch of packages to install.= I'm > probably missing some steps and obviously that's not a rigorous explanati= on but > it's at least O(n) where n is the total number of dependencies. not mutually exclusive. your n (number of deps) is different than my n (number of packages in portage). e.g. i think that : O(your n) =3D O(log(my n)) i think the real trick is to split portage into two separate parts: 1. index: pre-compiled indexed global dependency graph. this should allow efficient jumping into the right spot of the graph to efficiently walk around to meet the dependencies based on constraints (e.g. USE flags, versions). imo this can do the dependency resolution that emerge does in 45 seconds in less than 3 seconds. 2. scripts to carry out the compile/installation. currently portage has (1) and (2) mixed into a single directory-based structure containing files in a format that is not efficient for graph walking, and uses the wrong tool (python). > Speeding up portage would be a fun project but it's less important > that portage being correct. yes, the speed issue is not a problem (more like a psychological issue). but that's misleading. portage's problems is beyond the timing issue. e.g.: 1. the fact that emerge uses python is horrible. ideally a package manager must have least run-time dependencies possible. but now, emerge is based on python, which limits our freedom in upgrading python versions in the fear of wrecking emerge (and getting stuck, needing manual attention). which is why i think ideally new emerge should be some statically linked compiled binary. 2. i'm sure smart people can point out better reasons about how emerge is wrong.