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 13B8B158003 for ; Wed, 21 Jun 2023 17:59:58 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 9C455E09C8; Wed, 21 Jun 2023 17:59:44 +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 56C26E09C1 for ; Wed, 21 Jun 2023 17:59:44 +0000 (UTC) Received: by mail-oo1-xc2e.google.com with SMTP id 006d021491bc7-5607cdb0959so1974607eaf.2 for ; Wed, 21 Jun 2023 10:59:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fi-uba-ar.20221208.gappssmtp.com; s=20221208; t=1687370383; x=1689962383; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :from:to:cc:subject:date:message-id:reply-to; bh=Iwk9pyYkk+EenoV6RxU/o6KV5S7JqwRirnAjuOnVrn0=; b=0eTC6Kpu8t84fR3ZAtNPTRakeqlXqB2LGzzpwNVWID5UR3WmoMWxsdj7rNFDQdPXMt uKxGg32S+U08NbrVqIqQHwvWDgOJnqiVNW1IV7v872l/GzynS3cn+/9v8lcAFw3qtUvm kAIgFGKQ6ZH0ns+aZxbFTvI7Z/M3LgFSTWm3UZM3Ct6/Hhv7VSg5d0g+VgGpxKAAXtXv Mr5MElHRpFU6SLwleqWmnw83drKKUkYfoeINUSRMy+ZjTSBqKw2rB3ilnCFNIyzMmxtJ h4lJkdjdB/x5nhb221s0nvRe0piv/loXjL1yl0TOgMNO8APOPewaa7GkpBlo1j8u5/ZZ XmEw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1687370383; x=1689962383; 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=Iwk9pyYkk+EenoV6RxU/o6KV5S7JqwRirnAjuOnVrn0=; b=iE82rZVhjJ7giVZKCvLb4QRzGCb/5ysaG0P3pEMVoDimAY39iLxkYnKz/OMQz5w14q cTTKbuRJt3T2tym/mE85ut9eF1ifUPFG2Wy2Ex/D+kxf4+ySIZGT9am5WuwqC6SQQrI+ tJjspLKtvR3YC68PwHkiqPtCLRy0QtGK9MBTdQrvzYBOy08WSYkFjaxtImhaElaFGEgl v+QCROG0xvYIMF11ra552nF5ABARExmNwFLPU3jWb68ZCYq1fbv9H7BBC5oFSCIlRJcl hoGKliQXDGXxaunLwVFio+eshNAFoCHUJIZdcM2wyvHhyLi6NlIYBpb839mMwCJAiQ4g PXsQ== X-Gm-Message-State: AC+VfDyv7GUJrcl4mSM/KPwYdkSqSI2FS870nHfo+goSidb+0L/HOIc8 Va7YVRuAZLJOQgMPQHZm3BlOewe/j47Kwef5e7l6oHEZdUTVuK7LcmfWRg== X-Google-Smtp-Source: ACHHUZ4RJ4Szw1wG1Zpzlx+QPQ524yuGUvzMKVzHNf2vZWFRxsSleL0CssNODK7b3cFTW6JpcEUrkhsl893RNmwkZBE= X-Received: by 2002:a4a:df09:0:b0:55a:9fc5:c12c with SMTP id i9-20020a4adf09000000b0055a9fc5c12cmr8495893oou.5.1687370382055; Wed, 21 Jun 2023 10:59:42 -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 14:59:05 -0300 Message-ID: Subject: Re: [gentoo-dev] Eselect repository feature request To: gentoo-dev@lists.gentoo.org Content-Type: multipart/alternative; boundary="0000000000003a32c105fea7886e" X-Archives-Salt: 3c08e5b0-4b21-4436-adb1-c6b2be66f7fe X-Archives-Hash: 6259f59c5bb401482c97abafc072e81b --0000000000003a32c105fea7886e Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable > > I think flow's idea to make the sync command configurable somehow > would be sufficient, assuming there is demand for it. I agree. I'm glad Flow has their ideas straight. By the way Flow, could you share the links of the repo/PR so that we can follow the development along? I would love to see it! ^_^ I'm not quite certain what you mean by "module" here, but that sounds > like unnecessary extra abstraction. > I think my line of thought was a bit overkill. Not to mention that I am not that well versed (if at all) with portage's implementation detail. PS: I forgot to mention this in the original email, but I did file a bug with this feature request. https://bugs.gentoo.org/907959 El mi=C3=A9, 21 jun 2023 a las 14:46, Mike Gilbert () escribi=C3=B3: > On Wed, Jun 21, 2023 at 12:47=E2=80=AFPM TOMAS FABRIZIO ORSI > wrote: > > 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? > > I'm not quite certain what you mean by "module" here, but that sounds > like unnecessary extra abstraction. > > I think flow's idea to make the sync command configurable somehow > would be sufficient, assuming there is demand for it. > > --0000000000003a32c105fea7886e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I think = flow's idea to make the sync command configurable somehow
would be sufficient, assuming there is demand for it.
I agree.
I'm glad Fl= ow has their ideas straight.

<= div class=3D"gmail-adL">By the way Flow, could you share the links of the r= epo/PR so that we can
follow the develop= ment along? I would love to see it! ^_^
<= br>
I'm not quite certain what you mean by "module" here= , but that sounds
like unnecessary extra abstraction.
=C2=A0
I think my line of thought was a bit overkill.
Not to mention that I am not that well versed (= if at all)
with portage's implementat= ion detail.

PS: I forgot to mention this in the original email, but I did file a
bug with this feature request. https://bugs.gentoo.org/907959


El mi=C3=A9, 21 jun 2023 a las 14:46, Mike Gilbert= (<floppym@gentoo.org>) esc= ribi=C3=B3:
On W= ed, Jun 21, 2023 at 12:47=E2=80=AFPM TOMAS FABRIZIO ORSI <torsi@fi.uba.ar> wrote:
> 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 m= anager/sync program basis?

I'm not quite certain what you mean by "module" here, but tha= t sounds
like unnecessary extra abstraction.

I think flow's idea to make the sync command configurable somehow
would be sufficient, assuming there is demand for it.

--0000000000003a32c105fea7886e--