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 53A32158009 for ; Wed, 21 Jun 2023 19:16:36 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id DB8FFE0980; Wed, 21 Jun 2023 19:16:32 +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 95A09E0908 for ; Wed, 21 Jun 2023 19:16:32 +0000 (UTC) References: <30d4b57b-734f-bd42-4427-15389256e80f@gentoo.org> <703cdee8-b322-6c49-be13-efd10426ea6b@gentoo.org> <87bkh8zme0.fsf@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 20:16:15 +0100 In-reply-to: Message-ID: <87wmzwy6b7.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: 8bf35ec8-77a0-499f-885b-1eb80152405b X-Archives-Hash: 474499f09a8f0a4bb7834230f9a37676 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable TOMAS FABRIZIO ORSI writes: > 2. Add a way to use the "real" upstream sources instead of our mirrored > ones > >=20=20 > Isn't this eselect repository's default behaviour? Or am I misunderstandi= ng? > When I run "eselect repository list" I get the source repositories, not t= he mirrored ones. > Is it using the mirrored one behind the scenes? (Please don't top-post.) No, it uses the mirrores ones with metadata. > > Best regards, > - Tomas Fabrizio Orsi > El mi=C3=A9, 21 jun 2023 a las 15:44, Sam James () escrib= i=C3=B3: > > 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.c= onf's > >>>>>> 'master' key-value pair [1]? > >>>>>> > >>>>>> > >>>>>> Yes, I agree that it would be duplicating that information. As a = matter > >>>>>> of fact, Micha=C5=82 G=C3=B3rny pointed the same thing out. > >>>>>> However, Micha=C5=82 also added, quote: "What's really lacking he= re 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 'ma= sters' > >>>>> value from layout.conf, and add the missing repositories recursive= ly? > >>>> > >>>> That would be a significant change in behavior for eselect reposito= ry. > >>> > >>> 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+RkAUCZJNMjF8UgAAAAAAuAChp c3N1ZXItZnByQG5vdGF0aW9ucy5vcGVucGdwLmZpZnRoaG9yc2VtYW4ubmV0MjVB NkJCODhERDlCNzY0QzZCNTU0MUMyNzM4NDA5RjUyMERGOTE5MA8cc2FtQGdlbnRv by5vcmcACgkQc4QJ9SDfkZA0bAD/Wp+VfkZMPnJFVoFmfWQJN51D6K50xZQlG3i6 UmtCWbYA/Rqh03ZTu5uwtWefxPKXdqdo3df5lqmr+7+9RJD8IT4D =zcbt -----END PGP SIGNATURE----- --=-=-=--