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) server-digest SHA256) (No client certificate requested) by finch.gentoo.org (Postfix) with ESMTPS id 9C137158009 for ; Wed, 21 Jun 2023 18:44:03 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 04170E0986; Wed, 21 Jun 2023 18:44:00 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [IPv6:2001:470:ea4a:1:5054:ff:fec7:86e4]) (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 BF5FCE096B for ; Wed, 21 Jun 2023 18:43:59 +0000 (UTC) References: <30d4b57b-734f-bd42-4427-15389256e80f@gentoo.org> <703cdee8-b322-6c49-be13-efd10426ea6b@gentoo.org> User-agent: mu4e 1.10.3; emacs 29.0.92 From: Sam James To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] Eselect repository feature request Date: Wed, 21 Jun 2023 19:42:57 +0100 In-reply-to: Message-ID: <87bkh8zme0.fsf@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: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" X-Archives-Salt: f288958f-db39-42ba-ae2d-7092a9872410 X-Archives-Hash: 4548c5eee6de623487cc5098de14c510 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Florian Schmaus writes: > [[PGP Signed Part:Undecided]] > On 21/06/2023 17.56, Mike Gilbert wrote: >> On Wed, Jun 21, 2023 at 11:41=E2=80=AFAM Florian Schmaus wrote: >>> >>> On 20.06.23 19:26, Mike Gilbert wrote: >>>> On Tue, Jun 20, 2023 at 1:08=E2=80=AFPM Florian Schmaus wrote: >>>>> >>>>> On 20.06.23 16:41, TOMAS FABRIZIO ORSI wrote: >>>>>> Isn't that duplicating the information of metadata/layout.conf= 's >>>>>> 'master' key-value pair [1]? >>>>>> >>>>>> >>>>>> Yes, I agree that it would be duplicating that information. As a mat= ter >>>>>> of fact, Micha=C5=82 G=C3=B3rny pointed the same thing out. >>>>>> However, Micha=C5=82 also added, quote: "What's really lacking here = is >>>>>> support for specifying dependencies via |repositories.xml| >>>>> >>>>> Do we need to duplicate the information in repositories.xml, with all >>>>> the drawbacks of duplication? >>>>> >>>>> Can't eselect repository add the new repository, then read the 'maste= rs' >>>>> value from layout.conf, and add the missing repositories recursively? >>>> >>>> That would be a significant change in behavior for eselect repository. >>> >>> Right, but it seems to be a desirable behaviour. Cases where the user >>> wants to add a repo but not immediately sync it are probably rare. >>> >>> Furthermore, it would avoid duplicating the information, which avoids >>> the typical drawbacks of duplication (e.g., the two sets getting out of >>> sync). >>> >>> I've looked at the eselect-repository code, and it seems not hard to >>> change the behaviour of "eselect repository add" to add and sync a >>> repository and then, recursively, add and sync further required >>> repositories. >>> >>> I may give it a shot, but ideally I'd know if it has a chance to be >>> accepted upstream first. Or maybe there is a good reason why >>> eselect-repository behaves as it currently does that I am missing? >> I can't speak for "upstream", but here are my concerns: >> 1. As a developer, I might just want to create the repos.conf config >> snippet and sync the repo manually. >> 2. As a user, I might have any arbitrary reason for not wanting to >> sync immediately. > > Would an opt-out switch be enough to alleviate those concerns of you? > > >> 3. eselect-repository does not currently depend on any particular >> package manager. It writes config files intended for Portage, but it >> does not actually invoke any Portage commands. That feels like a >> significant distinction to me. >> 4. If you start invoking Portage commands, you then have to deal with >> the possibility of people using alternate package managers. pkgcore >> can also utilize Portage's repos.conf, and the user might prefer to >> use pmaint instead of emaint or emerge --sync. > > Those two points seem to be based on the same fundamental concern. > > The only portage specific code would be the call to "emaint sync -r > $repo" (remember that "emerge --sync" is just a wrapper for "emaint > sync --auto"). I think it would be easy to add later 1. add support > for different package managers (if the need arises), and 2. make the > "sync command" user configurable. While looking at this, it might be worth evaluating 2 other things which users have mentioned during the migration away from layman: 1. Adding a way to fully disable the cache fetching; 2. Add a way to use the "real" upstream sources instead of our mirrored ones best, sam --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iOUEARYKAI0WIQQlpruI3Zt2TGtVQcJzhAn1IN+RkAUCZJNE518UgAAAAAAuAChp c3N1ZXItZnByQG5vdGF0aW9ucy5vcGVucGdwLmZpZnRoaG9yc2VtYW4ubmV0MjVB NkJCODhERDlCNzY0QzZCNTU0MUMyNzM4NDA5RjUyMERGOTE5MA8cc2FtQGdlbnRv by5vcmcACgkQc4QJ9SDfkZCH6QEAgsLT2+V5b6g1Ybut7wcOhmJRY2n9wynNgNz+ PEr50P8BAIVf3zrr5TqCqewApq/BeLnI6z4Ha64an2Q89/Zge7sA =+O0Z -----END PGP SIGNATURE----- --=-=-=--