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 2595B158009 for ; Wed, 21 Jun 2023 16:48:04 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id DDEAFE0999; Wed, 21 Jun 2023 16:48:00 +0000 (UTC) Received: from mail-oo1-xc2e.google.com (mail-oo1-xc2e.google.com [IPv6:2607:f8b0:4864:20::c2e]) (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 A8FEAE0985 for ; Wed, 21 Jun 2023 16:48:00 +0000 (UTC) Received: by mail-oo1-xc2e.google.com with SMTP id 006d021491bc7-55e0706af99so4365634eaf.1 for ; Wed, 21 Jun 2023 09:48:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fi-uba-ar.20221208.gappssmtp.com; s=20221208; t=1687366079; x=1689958079; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :from:to:cc:subject:date:message-id:reply-to; bh=st3J2EGz9UBsxoNM9rKyQt6jOIzPQ3GfrLxtI+lqbXs=; b=Rz7oLBcN+6Sv2p5EzUT+PI2IYDImtAR1FIxTOSziI4m7gJOxUs0VlTBifYoCvgL/sJ 2hOtf+Wer71wRb9q/nJrz6OejidXEBDw/rylI6U8VbKY1wuFntEBUrITtFPWiWW1+rzk xLcLzJK5lLrXTxxahtNOgL2aAQD2Ewn43RUKS5pM/vLB9q4Pz4+DMbaD6tuCU44xi9hX P9y/dP2jWNXFRWTa1vbwkiFrGP7H1jaTTx9mz+BTIaOxfglcb6cgTQvmMf02ExKKMETg HGUZkqNT3+fmAvwg3h/2A7oU1f4dBCI5eQQ4l8CkWZGNnCsqKgKFpEhGekaKi1yVGIrE xFag== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1687366079; x=1689958079; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=st3J2EGz9UBsxoNM9rKyQt6jOIzPQ3GfrLxtI+lqbXs=; b=T3W8m+WwfMno3o5XE6Ruv9yjNbeiUb/LOeUlnMgniKB16rcpgmKYOqhWi31VQ9MtKF o+NVGFIzUEEWpevH3dSyiGORcesWsaEL/k862geJb5izASu4wVwJGRdJL5PHrJIzR/SQ aGiGTRS7Yo5kETzhBUj0L4exRftPo55MR9+qCJWleiRwuKkZoyW+9Z2HCB2GxhLKzeHM PbIewmZpD2B9QmNgY2pEEGm0JDb4Pd6g5W/WDZZQ3c28zvgyEUrjuuRD0Ryad3tsb9ro gC+DGLEn/36n0UEqj1UrG9gI5YM0kGMDLdkkYjHKyga9ytOhR3LyHdNU3fc6GmFq3Ct9 GjIQ== X-Gm-Message-State: AC+VfDyDXAauUIY1mSXeS58ZcDvk4C+XU+vBL0DU7KqL5cv34bPvkQam hWJje8VElczPg8pM2Or1zZlstybbK5gavCk1x56rZKo4vc667Wj0MdxHiw== X-Google-Smtp-Source: ACHHUZ5tErNrKTaT9+ltPO5DWO2uOhGHuvgale1dlU7GR0G2y2s7WQuFiOrVAUqlr59t/KZVeTot7N1XbSuXcFQq8i0= X-Received: by 2002:a4a:d451:0:b0:558:b424:8c31 with SMTP id p17-20020a4ad451000000b00558b4248c31mr5372407oos.0.1687366079350; Wed, 21 Jun 2023 09:47:59 -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: TOMAS FABRIZIO ORSI Date: Wed, 21 Jun 2023 13:47:23 -0300 Message-ID: Subject: Re: [gentoo-dev] Eselect repository feature request To: gentoo-dev@lists.gentoo.org Content-Type: multipart/alternative; boundary="000000000000c41e6505fea687ff" X-Archives-Salt: 4735925d-1024-4dea-9d74-9940ec638654 X-Archives-Hash: 11c7a680c25aca6f2e5080f60390a9e3 --000000000000c41e6505fea687ff Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable > > 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. As a matter of fact, Micha=C5=82 G=C3=B3rny raised the same questions: "A bit of a problem is how to design UI in eselect-repository. I'm not 100% sure that having it automatically install dependent repositories without confirmation is a good idea" ( https://github.com/projg2/eselect-repository/issues/20#issuecomment-1579288= 719) Ideally, confirmation would be asked before proceeding to sync the other overlays. I agree that doing something without the user's knowledge is not ideal. 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. I had not considered that possibility either. In that case, could not the overlay dependency resolution be handled as a module? Said module could be a common interface for different package managers. Then, the execution of said module would be handled on a per package manager/sync program basis? Best regards, - Tomas Fabrizio Orsi El mi=C3=A9, 21 jun 2023 a las 12:57, Mike Gilbert () escribi=C3=B3: > 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 > 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 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 > 'masters' > > >> 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. > > --000000000000c41e6505fea687ff Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
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.
As a matter of fact, Micha=C5=82 G=C3=B3rny raised = the same questions:
"A bit of a problem is how to design UI in eselect-repository. I'm not 100% s= ure
that having it automatically install dependent repositor= ies without confirmation is a good idea"
Ideally, confirmation would be asked before proceedin= g to sync the other overlays.
I agree that doing something withou= t the user's knowledge is not ideal.

3. eselect-repository does not cur= rently 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.

I had not co= nsidered that possibility either. In that case, could not the overlay
=
dependency resolution be handled as a module?
Said modu= le could be a common interface for different package managers.
Then, the execution of said module would be handled on a per package ma= nager/sync program basis?

Best regards,
= - Tomas Fabrizio Orsi

El mi=C3=A9, 21 jun 2023 a las 12:57, Mike Gilbe= rt (<floppym@gen= too.org>) escribi=C3=B3:
On Wed, Jun 21, 2023 at 11:41=E2=80=AFAM Florian Schmaus &l= t;flow@gentoo.org&= gt; wrote:
>
> On 20.06.23 19:26, Mike Gilbert wrote:
> > On Tue, Jun 20, 2023 at 1:08=E2=80=AFPM Florian Schmaus <flow@gentoo.org> wro= te:
> >>
> >> On 20.06.23 16:41, TOMAS FABRIZIO ORSI wrote:
> >>>=C2=A0 =C2=A0 =C2=A0 Isn't that duplicating the inform= ation of metadata/layout.conf's
> >>>=C2=A0 =C2=A0 =C2=A0 'master' key-value pair [1]?<= br> > >>>
> >>>
> >>> Yes, I agree that it would be duplicating that informatio= n. As a matter
> >>> of fact, Micha=C5=82 G=C3=B3rny pointed the same thing ou= t.
> >>> 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 rea= d the 'masters'
> >> value from layout.conf, and add the missing repositories recu= rsively?
> >
> > That would be a significant change in behavior for eselect reposi= tory.
>
> Right, but it seems to be a desirable behaviour. Cases where the user<= br> > wants to add a repo but not immediately sync it are probably rare.
>
> Furthermore, it would avoid duplicating the information, which avoids<= br> > 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 b= e
> 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.

--000000000000c41e6505fea687ff--