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 5752B158009 for ; Wed, 21 Jun 2023 17:29:10 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 13645E09B6; Wed, 21 Jun 2023 17:29:07 +0000 (UTC) Received: from smtp.gentoo.org (dev.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)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id C57D9E09B1 for ; Wed, 21 Jun 2023 17:29:06 +0000 (UTC) Received: by mail-yb1-f178.google.com with SMTP id 3f1490d57ef6-bb3a77abd7bso6126086276.0 for ; Wed, 21 Jun 2023 10:29:06 -0700 (PDT) X-Gm-Message-State: AC+VfDwVnaQscY8lpeIzZYN9t3krjdGmYVqshIFp28lbOCu4mjYZMk4b r7NC6WRixdiswl3DvHYgGkKvA7757pRnZ3jPeb8= X-Google-Smtp-Source: ACHHUZ5fnt1y8OSIj2IjbWa9bWlg4Yb3rzsFzjiPrIKIpdiel9aP13vHYxn54WwzKlI1nBjk0monbvKPoBplbS9Jav0= X-Received: by 2002:a25:ad9f:0:b0:b8f:5639:cb8a with SMTP id z31-20020a25ad9f000000b00b8f5639cb8amr13521112ybi.9.1687368544155; Wed, 21 Jun 2023 10:29:04 -0700 (PDT) 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 References: <30d4b57b-734f-bd42-4427-15389256e80f@gentoo.org> <703cdee8-b322-6c49-be13-efd10426ea6b@gentoo.org> In-Reply-To: From: Mike Gilbert Date: Wed, 21 Jun 2023 13:28:52 -0400 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [gentoo-dev] Eselect repository feature request To: gentoo-dev@lists.gentoo.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Archives-Salt: 4f1b664a-2a5b-4f4c-8957-4bc9d9c5886a X-Archives-Hash: c1f04f300ce70366a55a01189caaddab On Wed, Jun 21, 2023 at 12:49=E2=80=AFPM Florian Schmaus = wrote: > > 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.con= f's > >>>>> 'master' key-value pair [1]? > >>>>> > >>>>> > >>>>> Yes, I agree that it would be duplicating that information. As a ma= tter > >>>>> 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 al= l > >>>> the drawbacks of duplication? > >>>> > >>>> Can't eselect repository add the new repository, then read the 'mast= ers' > >>>> 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 o= f > >> 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? Yes. > > > 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. Sure, that seems sensible.