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 94702158009 for ; Wed, 21 Jun 2023 15:56:58 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 4C12EE096B; Wed, 21 Jun 2023 15:56:55 +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 09214E095A for ; Wed, 21 Jun 2023 15:56:55 +0000 (UTC) Received: by mail-yw1-f173.google.com with SMTP id 00721157ae682-5702415be17so53702057b3.2 for ; Wed, 21 Jun 2023 08:56:54 -0700 (PDT) X-Gm-Message-State: AC+VfDxXj6LIONaxIrYHro+9t2cFhd3KDFgJNlSV2Lz9N9jq9tKF40MP gDbCk87AbEAU6KFU3VQ5WZ18EGjQSoHGuI6T7vw= X-Google-Smtp-Source: ACHHUZ5Vmp+3jqpXbjQSrxIJ+5QejosNKhGARBgTnxJ2JGOArV3ubWRULj2JkKjNOKRAefzTfBRcGdKt2slXw5+iboc= X-Received: by 2002:a0d:d681:0:b0:561:81b:7319 with SMTP id y123-20020a0dd681000000b00561081b7319mr12825850ywd.32.1687363012166; Wed, 21 Jun 2023 08:56:52 -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 11:56:41 -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: 59eafcac-541b-4a8b-b154-cf0ddfea8b1f X-Archives-Hash: e767771d09b22d62eb06b7a4033db59c 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 matt= er > >>> 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 i= s > >>> 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 'master= s' > >> 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. 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.