From debbugs-submit-bounces@debbugs.gnu.org Sun Nov 14 14:05:49 2021 Received: (at 51845) by debbugs.gnu.org; 14 Nov 2021 19:05:50 +0000 Received: from localhost ([127.0.0.1]:51722 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mmKp3-0004v5-Ma for submit@debbugs.gnu.org; Sun, 14 Nov 2021 14:05:49 -0500 Received: from mail-wm1-f65.google.com ([209.85.128.65]:35332) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mmKp2-0004us-06 for 51845@debbugs.gnu.org; Sun, 14 Nov 2021 14:05:48 -0500 Received: by mail-wm1-f65.google.com with SMTP id 77-20020a1c0450000000b0033123de3425so14080882wme.0 for <51845@debbugs.gnu.org>; Sun, 14 Nov 2021 11:05:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=message-id:subject:from:to:cc:date:in-reply-to:references :user-agent:mime-version:content-transfer-encoding; bh=0xP6lSOtBHyfb6IuswYu9DbLhUF7tCbl8+rtttSjPBQ=; b=S3lRCuv+1qMMCc4KTgPD5hxKj06j90fixjJQrHXiB0zhX9Tl73usQwuasEMP0DV2sx +dA7elR0sqjD5f62C4+RwLIcv/Y8yLNERudj4Hew75Cq1wZ0xGFYzA0pYS1vsUApCPBJ RN7dZOqAOQX5/jysrfQWCep2obr2JhpV2deFSJCSJPiHxRhDogCgsTWb1OrMUW2d0jbf G0vwjq6gLDEK+e5QHBWxfWQBn6fw0668pt5bEZjaGEL6Db7Af/onuEwsCX6g0+n3GksC jLiBUoQ6bIe9heCv2yD2CarCEy8dO2ri24nYjEgiDpNCoLXXVbNtIJI4lsy7hO0i4P8U kNHw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:subject:from:to:cc:date:in-reply-to :references:user-agent:mime-version:content-transfer-encoding; bh=0xP6lSOtBHyfb6IuswYu9DbLhUF7tCbl8+rtttSjPBQ=; b=CvXj8Ebj8wtR/AL6m0sRrfzNBtNUzsFfHf+cqwuzUMsm7+UH1Kec8mAl2UXEOCb+31 sdbyY2yvVV19CcuJeSj1tehNNHA2yRkwSRcO825RdVNiDR2YXFLtk5ufsVw1xIU7KNG4 TdSN0A5063abVSrVVrGbYU/wmqunjtNrou+llNUjkHPcHzPZkQu7lKoXh5xYAhFGHFxH wiovqSkjWNh4OEzH7cy6nPOpLU2QtD0kVNIYHBAxZ7F2WR7XpSCmURlloDvGKg0MHezv 3M01n1OQmpDkldTfN1EoE1prq+DSmCEYeqKER1V8QXwSKVJOMpZtw2utKZErkOJ6pndP 1U1Q== X-Gm-Message-State: AOAM53073DlPrC+PwdgqyRD5+DVuYBionqttzRS2P9DPQuWJqDQN3Z6i DKfDZjerYQU8M9MdTw41FeIeOfR5FrNqZw== X-Google-Smtp-Source: ABdhPJx5GPYI/sPHXnmGlO1JikkouVL5UUfTy3Pd/vWUhMSBMf1EAnQCApjx5qU+itbR8UF/1w3W6w== X-Received: by 2002:a05:600c:2f01:: with SMTP id r1mr36553277wmn.153.1636916741955; Sun, 14 Nov 2021 11:05:41 -0800 (PST) Received: from nijino.fritz.box (85-127-52-93.dsl.dynamic.surfer.at. [85.127.52.93]) by smtp.gmail.com with ESMTPSA id c16sm11635361wrx.96.2021.11.14.11.05.32 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 14 Nov 2021 11:05:38 -0800 (PST) Message-ID: <49868b918eb291fd2761c48c7617fecd6bb98764.camel@gmail.com> Subject: Re: [PATCH 0/2] Add librsvg-bootstrap From: Liliana Marie Prikler To: Efraim Flashner Date: Sun, 14 Nov 2021 20:05:30 +0100 In-Reply-To: References: <68012880ef968bf2d5ab3d7e967b06bafb9ea10f.camel@gmail.com> Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.34.2 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 51845 Cc: 51845@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Hi, Am Sonntag, den 14.11.2021, 20:07 +0200 schrieb Efraim Flashner: > > As a temporary resolution to the rebuild issue, we could pin the > > dependencies of librsvg to some specific versions and only bump > > them something awful happens. I'm not sure whether librsvg > > exposes any of the Rust nastiness to its dependencies, ideally > > hoping that it would not. > > I don't believe librsvg exposes any rust-y stuff. That sounds like a good start for once. > > WDYT? > > (ins)efraim@3900XT /tmp/librsvg-2.50.7$ ls vendor/ | wc -l > 226 > > There are 226 crates that upstream bundles with their source. I > suppose we could pare it down to about 200 by careful pruning but > it's part of librsvg and not going away. Well, I'd suggest snippeting them away, but that's a different topic. > (ins)efraim@3900XT ~/workspace/guix-core-updates$ git grep \,librsvg > | wc -l > 103 I'd hazard a guess that most if not all of these 103 packages are themselves gtk-adjacent, so what really is the issue we're solving here? What is the point of maintaining an extra version for 101 of them when a potentially vulnerable GTK sits right next to them? > I'm suggesting that for gtk+@2 and gtk+@3 we use the bundled crates > and for the other 101 packages we continue to use our current > version, where we replace all of the bundled crates with our own > copies, which get updated more often than librsvg does. > > With our current rust tooling I don't think it'd be that easy to find > the ~226 crates that librsvg depends on, and it wouldn't be great to > lock them due to librsvg being an input for gtk2/3. Said input exists due to gdk-pixbuf+svg, with the +svg part being largely optional – the most common failure mode of it not being included are broken button textures, which we could fix by pre- rendering images with a suitable tool, such as inkscape. We could easily do a minimal gtk[+]? without it. As for the lock, why can't we? gtk+ is already core-updates material, so it stands to reason that anything causing it to rebuild is too. Rather than push down blobs to the users because we can't deal with Rust, we should fix Rust or make it go away from the build. WDYT?