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.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by finch.gentoo.org (Postfix) with ESMTPS id 86AA9158094 for ; Tue, 5 Jul 2022 19:55:44 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 2893DE0ED0; Tue, 5 Jul 2022 19:55:40 +0000 (UTC) Received: from smtp.gentoo.org (woodpecker.gentoo.org [140.211.166.183]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id CDF7EE0EB5 for ; Tue, 5 Jul 2022 19:55:39 +0000 (UTC) Date: Tue, 5 Jul 2022 15:55:33 -0400 From: Kenton Groombridge To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] [PATCH] linux-mod.eclass: support module signing Message-ID: <20220705195533.lezywdb7ufp2dzfv@fuuko> References: <84e99a74d64f0d9dd326af0f2c54b9d5717b2f8d.camel@gentoo.org> <9317f3aa1815d9ef219625794c06a8fb3057d707.camel@gentoo.org> <20220627183531.palnmdpvgzf44ssk@fuuko> <7311bbf9de54e3fb08953a40a9cd03df61f4dd00.camel@gentoo.org> <0f4a80cb6ee817dc015c1791960df032ae528ea4.camel@gentoo.org> <3e82436e9883431e59daf011b60deaffae1a3268.camel@gentoo.org> Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org X-Auto-Response-Suppress: DR, RN, NRN, OOF, AutoReply MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3e82436e9883431e59daf011b60deaffae1a3268.camel@gentoo.org> X-Archives-Salt: 0e79ac0d-c221-4ba8-ab23-75e1521fa295 X-Archives-Hash: 801d7c8d63616087e2bf81f13f776e93 On 22/07/05 12:02PM, Georgy Yakovlev wrote: > started playing with my old code and got blocked right away: > > looks like dostrip just creates a list of files/directories to strip > and processed at the very end of install phase. > > so skipping strip and doing manual one might be problematic. > internally portage uses estrip > https://github.com/gentoo/portage/blob/master/bin/estrip > which contains quite a lot of logic and code and I don't think > partially re-implementing this in eclass code is appropriate. > I agree I don't think it's appropriate. Would it make sense to be able to provide an extra argument to dostrip in order to strip an object *now* using the existing logic (and skip later stripping)? i.e.: dostrip --now my_module.ko