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 9FBFD158009 for ; Wed, 21 Jun 2023 19:03:54 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id CBC0CE0995; Wed, 21 Jun 2023 19:03:50 +0000 (UTC) Received: from mail-oo1-xc2f.google.com (mail-oo1-xc2f.google.com [IPv6:2607:f8b0:4864:20::c2f]) (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 A2478E0872 for ; Wed, 21 Jun 2023 19:03:50 +0000 (UTC) Received: by mail-oo1-xc2f.google.com with SMTP id 006d021491bc7-55e42149cf2so2920805eaf.2 for ; Wed, 21 Jun 2023 12:03:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fi-uba-ar.20221208.gappssmtp.com; s=20221208; t=1687374229; x=1689966229; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :from:to:cc:subject:date:message-id:reply-to; bh=6A9wBe8V6gnDUBuunACW264Ka7/jwmF40+NUTfKFfDw=; b=d0TOpoCZZqxjgrWpN4BaB6E02HL5wJUJmNGWIWuxJqNZuMmtJoQqfjKEWAWFOK8gM/ edlLpoFsvClvDCJSq9O9Sr1eyPVQwowFZ/c/vKtQLazL9gl+sQpnqXqK7p2uWhdpdJ+t MGqU9k6P6LQh93/CEqWYNDptei9lVBTAxkEbVEwqAEirrYYT+aw7+vwrJOpsk0IGa8tw 4p8afP7oq+NDJJXgvmn8Wg6JVMMqVnzFZIrgBMCMLBjHD7kTY/8+UN8DvDcaBzbzpHpg 1cUub/TIlgiOhgfzT+Fvxx3INZw9cdsuHTVWt4CITGjdYu/mkmnpwtnQ825ce4/QCv// zpEw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1687374229; x=1689966229; 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=6A9wBe8V6gnDUBuunACW264Ka7/jwmF40+NUTfKFfDw=; b=QlZogxIhrYzj5dm6dCydidQ4Q0NMh0fNezEVSiL8FJ+gubZF8/d0WcBL0a/zz3rk3w U/BiJVGRVI/PBn3MKKDy+CZIZzQzxFJNyUc66lyUtW7lHTRPQ8XOyrOEeZIiWGxkzwRj S/NXRSZevmbclND2B4ZDIh9MGC6crsXUIMvQwI2G0/KrbdcShIX+yavd9ByBLet3xFgJ aeGGf/jLbvkH2J9t46sDmcmYE2c1whjEsj0UY6zXJ+08CB3ipW6ZrA5reol7lxciTLgE iEcYYE+6qK3YNVg4tvY/YzeOCflasXd5/C8oAVkFQ2Zr9SJ6GKz1+uULbrvv5IH9iooP DWiA== X-Gm-Message-State: AC+VfDy+f4kWv0b8aaNVmJBrVTj80yyLbXF1yu4sfnXHvH4ED493iy0d Ov1HFW/woH1PR3xbwlUXWcZ17KGP4mKPqz/tsxw0WqB6OzDijEfC+l+ipg== X-Google-Smtp-Source: ACHHUZ7DDYoNyLRJjSIt7uGHvShQgycgDsjA2ug/4uj4u29jKoZHZdNWWJA0aw2tUKPGdQMabQx+U7XX350vjvj+1i4= X-Received: by 2002:a4a:a684:0:b0:560:8dcd:5f24 with SMTP id f4-20020a4aa684000000b005608dcd5f24mr4759470oom.8.1687374229229; Wed, 21 Jun 2023 12:03:49 -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> <87bkh8zme0.fsf@gentoo.org> In-Reply-To: <87bkh8zme0.fsf@gentoo.org> From: TOMAS FABRIZIO ORSI Date: Wed, 21 Jun 2023 16:03:13 -0300 Message-ID: Subject: Re: [gentoo-dev] Eselect repository feature request To: gentoo-dev@lists.gentoo.org Content-Type: multipart/alternative; boundary="00000000000089605305fea86d0d" X-Archives-Salt: e089774f-c015-4fa6-af90-c72e0c0b836f X-Archives-Hash: aa2dbeb4997ad75b58637a266f1f6f6d --00000000000089605305fea86d0d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable > > 2. Add a way to use the "real" upstream sources instead of our mirrored > ones Isn't this eselect repository's default behaviour? Or am I misunderstanding= ? When I run "eselect repository list" I get the source repositories, not the mirrored ones. Is it using the mirrored one behind the scenes? Best regards, - Tomas Fabrizio Orsi El mi=C3=A9, 21 jun 2023 a las 15:44, Sam James () escribi= =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.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 her= e is > >>>>>> support for specifying dependencies via |repositories.xml| > >>>>> > >>>>> Do we need to duplicate the information in repositories.xml, with a= ll > >>>>> 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 recursivel= y? > >>>> > >>>> That would be a significant change in behavior for eselect repositor= y. > >>> > >>> 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 > --00000000000089605305fea86d0d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
2. Add a way to use the "real" upstream sources instea= d of our mirrored
ones
=C2=A0
Isn't this eselect reposit= ory's default behaviour? Or am I misunderstanding?
When I run= "eselect repository list" I get the source repositories, not the= mirrored ones.
Is it using the mirrored one behind the scenes?

Best regards,
- Tomas Fabrizio Orsi
El mi=C3=A9, 21 jun 2023 a las 15:44= , Sam James (<sam@ge= ntoo.org>) escribi=C3=B3:

Florian Schmaus <fl= ow@gentoo.org> 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 <flow@gentoo.org> wro= te:
>>>
>>> On 20.06.23 19:26, Mike Gilbert wrote:
>>>> On Tue, Jun 20, 2023 at 1:08=E2=80=AFPM Florian Schmaus &l= t;flow@gentoo.org&= gt; wrote:
>>>>>
>>>>> On 20.06.23 16:41, TOMAS FABRIZIO ORSI wrote:
>>>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0Isn't that duplicati= ng the information of metadata/layout.conf's
>>>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0'master' key-val= ue pair [1]?
>>>>>>
>>>>>>
>>>>>> Yes, I agree that it would be duplicating that inf= ormation. As a matter
>>>>>> of fact, Micha=C5=82 G=C3=B3rny pointed the same t= hing out.
>>>>>> However, Micha=C5=82 also added, quote: "What= 's really lacking here is
>>>>>> support for specifying dependencies via |repositor= ies.xml|
>>>>>
>>>>> Do we need to duplicate the information in repositorie= s.xml, with all
>>>>> the drawbacks of duplication?
>>>>>
>>>>> Can't eselect repository add the new repository, t= hen read the 'masters'
>>>>> value from layout.conf, and add the missing repositori= es recursively?
>>>>
>>>> That would be a significant change in behavior for eselect= repository.
>>>
>>> Right, but it seems to be a desirable behaviour. Cases where t= he user
>>> wants to add a repo but not immediately sync it are probably r= are.
>>>
>>> Furthermore, it would avoid duplicating the information, which= avoids
>>> the typical drawbacks of duplication (e.g., the two sets getti= ng out of
>>> sync).
>>>
>>> I've looked at the eselect-repository code, and it seems n= ot hard to
>>> change the behaviour of "eselect repository add" to = add and sync a
>>> repository and then, recursively, add and sync further require= d
>>> repositories.
>>>
>>> I may give it a shot, but ideally I'd know if it has a cha= nce to be
>>> accepted upstream first. Or maybe there is a good reason why >>> eselect-repository behaves as it currently does that I am miss= ing?
>> I can't speak for "upstream", but here are my concer= ns:
>> 1. As a developer, I might just want to create the repos.conf conf= ig
>> 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?<= br> >
>
>> 3. eselect-repository does not currently depend on any particular<= br> >> 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 w= ith
>> the possibility of people using alternate package managers. pkgcor= e
>> can also utilize Portage's repos.conf, and the user might pref= er 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 suppo= rt
> 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 mi= rrored
ones

best,
sam
--00000000000089605305fea86d0d--