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 28F0A158009 for ; Sun, 18 Jun 2023 20:40:08 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id CFC65E0900; Sun, 18 Jun 2023 20:40:03 +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 76E04E08BD for ; Sun, 18 Jun 2023 20:40:03 +0000 (UTC) Received: by mail-oo1-xc2f.google.com with SMTP id 006d021491bc7-55e1bb2ab1aso1705411eaf.2 for ; Sun, 18 Jun 2023 13:40:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fi-uba-ar.20221208.gappssmtp.com; s=20221208; t=1687120802; x=1689712802; h=to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=adugPm1U0EY3AdtidBOtbF2JI9Goqg2d2vGKTB/jmiM=; b=vOP9wclMIqb8UNWUcmen4UIY0ZICvx5WkaIIHx7NDitdaQL0guyyp+oEDjF5wUSOAa XRIUAyMFsPRUerNkCdCgqIb3kr9EjTAEU5pZd/P40bSkOKCz4wrbgE/oLFTdnowx01Y1 XTKWgI/2MgF3A+1AmjlDRLmU/MvuDOEDDDjpeU1n5gfstl4KBQobsvHtdaEOUSOIiSjI bNpXGBvpwbhxXKuoekQvCa/+OXJ8BWyZdGdHbsF2dBUnKZNN8EKg9Uf7fTd9x/5nvhpp W/ojG9GoHNf90WcHkYoRRg2Y85CwtUPkkqX3wBou9lzsrNrvYyQ1RD7XjgkZTLNhSjfO IpFg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1687120802; x=1689712802; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=adugPm1U0EY3AdtidBOtbF2JI9Goqg2d2vGKTB/jmiM=; b=C4opXznjNDqVOq9VvM8PUL2Vt3jh4RGDlwAQB/GPtKrEwCCWMcB6bYOS/CIcUBzh31 WmQV7qsUxUauXGma6A+Mia2zy8D2OSSiPMSQqN47upynHR1zWLDnem1Ne3ctuxlEbvWd Tvqyiir2UmDr801Qfslvoq+pAxf19Rtn9OeqYfV3f8BcPLY8OzD7/ZIqzElEWrU8YCYK Q7Dpu4huEmMi7nng4LhcY3KowjiL8zrWNlmzbXg6VTG5yqhdYTtdBLbhl9jcuWGUd3VR ZGBXxemDxvazjCxD9UlaP/tr2qeufQ7sUNFpTylMOnmDJr5/mG8TAxpAg1sGxgGMlm5r RyGg== X-Gm-Message-State: AC+VfDwrTWi1/YMA3tvE8Ng/UE28PUninKhW7aRMBFiw5QeVPy67L0Nc /7y7AR+uGYRuSp/TnNEf5NquQodAr9/99CwveeikRgJ8B1qO0yqpUdENrA== X-Google-Smtp-Source: ACHHUZ5COpMNvxM4Y2YnLQz+A+nakvRPUBNfpGw9wo+AfkuIz/w3G9rkYepORTlmO4OoWZpVz59FNiY74SFUDj11HQs= X-Received: by 2002:a4a:be84:0:b0:55a:f44b:43cd with SMTP id o4-20020a4abe84000000b0055af44b43cdmr5543438oop.7.1687120802180; Sun, 18 Jun 2023 13:40:02 -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 From: TOMAS FABRIZIO ORSI Date: Sun, 18 Jun 2023 17:39:26 -0300 Message-ID: Subject: [gentoo-dev] Eselect repository feature request To: gentoo-dev@lists.gentoo.org Content-Type: multipart/alternative; boundary="0000000000001b842b05fe6d6c85" X-Archives-Salt: 3b2e3095-1e6e-414e-b369-74bd23e8c692 X-Archives-Hash: 237bab78de82b746d07eaa2ce0fc2622 --0000000000001b842b05fe6d6c85 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hello gentoo devs. The other day I made a feature suggestion to the eselect repository github page. (Here's the link: https://github.com/projg2/eselect-repository/issues/20). Micha=C5=82 G=C3=B3rny suggested that I should contact the gentoo-dev maili= ng list with my suggestion, so here it is: My suggestion is to make it possible for eselect repository to manage overlay dependencies. As it stands, and as far as I'm concerned, there is no "proper" way of having an ebuild dependency from another overlay. So overlay writers have to copy ebuilds from other overlays or rewrite them. This implies synchronization issues (where the "copied" ebuilds get out of sync from the original ebuild) and time loss (people writing the same ebuild more than once). Micha=C5=82 G=C3=B3rny suggested that I should make an edit to the reposito= ries.xml file in order to tackle the issue. This is my general idea: (I am using the github template as an example, but the idea should apply to all other templates. I got this file from https://github.com/gentoo/api-gentoo-org/blob/master/files/overlays/reposit= ories.xml ). * GITHUB TEMPLATE XXXXX XXXXXX https://github.com/XXXX/xxxx XXXXX XXXXX https://github.com/XXXX/xxxx.git git+ssh://git@github.com/XXXX/xxxx.git https://github.com/XXXX/xxxx/commits/master.atom overlayName (the only thing I added is the item) The item would be a list of overlay dependencies (it could be empty). It would be represented as a list of repository names that the overlay depends on. Said dependencies could be stated in the master file (since this would "extend" its behavior) The algorithm would use a queue ("dependencies" queue) and a set ("overlays to be added" set) It starts by creating the "dependency" queue. After that it adds to the queue the overlay the user specifically asked for. The dependency algorithm would look like this: 1. If the queue is empty the algorithm stops 2. Checks the first overlay in the queue's dependencies list 3. If the dependencies list is empty, it does nothing 4. If it says that there is a dependency that the user has already enabled in their system, it does nothing 5. If the dependency is already in the set of "overlays to be added", it does nothing* 6. If not 2 or 3 or 4, it adds the dependency to the set of "overlays To be added" and adds said repository to the queue 7. It "pops" the first item on the queue and repeats the algorithm *There reason why it is a set is because there is no need to check for circular dependencies in overlays. Once the algorithm is finished it would print out something like this foo overlay (the one the user wants to add) depends on bar overlay. Would you like to add bar as well? Y/N If yes: bar overlay depends on biz overlay. Would you like to add biz as well? Y/N And so on ------ PROS: Fairly simple algorithm. CONS: Unwanted overlays with packages the user will never use. The main con is that even though the overlay is marked as "dependency", not *all* packages depend on the other overlays: Only a few. Having said that, this can be mitigated with only minimal manual intervention by the user. I would love to get feedback on this idea and what are some of its shortcomings/things that I missed/haven't considered yet. Thanks in advance and thank you for making gentoo so great. Have a good day - Tomas Fabrizio Orsi a.k.a Lima Limon --0000000000001b842b05fe6d6c85 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello gentoo devs. The other day I made a feature sug= gestion to the eselect repository github page. (Here's the link: https://github= .com/projg2/eselect-repository/issues/20).
Micha=C5=82 G=C3= =B3rny suggested that I should contact the gentoo-dev mailing list with my = suggestion, so here it is: My suggestion is to make it possible for eselect= repository to manage overlay dependencies.

As it stands, and= as far as I'm concerned, there is no "proper" way of having = an ebuild dependency from another overlay. So overlay writers have to copy = ebuilds from other overlays or rewrite them. This implies synchronization i= ssues (where the "copied" ebuilds get out of sync from the origin= al ebuild) and time loss (people writing the same ebuild more than once).

Micha=C5=82 G=C3=B3rny suggested that I should mak= e an edit to the repositories.xml file in order to tackle the issue.

This is my general idea:
(I am using the github= template as an example, but the idea should apply to all other templates. = I got this file from https://github.com/gentoo/api-ge= ntoo-org/blob/master/files/overlays/repositories.xml).

=C2=A0 * = GITHUB TEMPLATE
=C2=A0 =C2=A0 <repo quality=3D"experimental"= ; status=3D"unofficial">
=C2=A0 =C2=A0 =C2=A0 <name>X= XXXX</name>
=C2=A0 =C2=A0 =C2=A0 <description lang=3D"en&q= uot;>XXXXXX</description>
=C2=A0 =C2=A0 =C2=A0 <homepage>= https://github.com/XXXX/xxxx&l= t;/homepage>
=C2=A0 =C2=A0 =C2=A0 <owner type=3D"person"= >
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <email>XXXXX</email>
=C2= =A0 =C2=A0 =C2=A0 =C2=A0 <name>XXXXX</name>
=C2=A0 =C2=A0 = =C2=A0 </owner>
=C2=A0 =C2=A0 =C2=A0 <source type=3D"git&q= uot;>https://github.com/XXX= X/xxxx.git</source>
=C2=A0 =C2=A0 =C2=A0 <source type=3D&qu= ot;git">git+ssh://g= it@github.com/XXXX/xxxx.git</source>
=C2=A0 =C2=A0 =C2=A0 <= feed>https:= //github.com/XXXX/xxxx/commits/master.atom</feed>
=C2=A0 =C2= =A0 =C2=A0 <dependencies>
=C2=A0 =C2=A0=C2=A0 =C2=A0 =C2=A0=C2= =A0 <name>overlayName</name>
=C2=A0 =C2=A0 =C2=A0 </depen= dencies>
=C2=A0 =C2=A0 </repo>

(the on= ly thing I added is the <dependencies> item)
The <dependencies&= gt; item would be a list of overlay dependencies (it could be empty). It wo= uld be represented as a list of repository names that the overlay depends o= n. Said dependencies could be stated in the master file (since this would &= quot;extend" its behavior)

The algorithm would use a queue (&qu= ot;dependencies" queue) and a set ("overlays to be added" se= t)
It starts by creating the "dependency" queue. After that it= adds to the queue the overlay the user specifically asked for.

The = dependency algorithm would look like this:
1. If the queue is empty the = algorithm stops
2. Checks the first overlay in the queue's dependenc= ies list
3. If the dependencies list is empty, it does nothing
4. If = it says that there is a dependency that the user has already enabled in the= ir system, it does nothing
5. If the dependency is already in the set of= "overlays to be added", it does nothing*
6. If not 2 or 3 or = 4, it adds the dependency to the set of "overlays To be added" an= d adds said repository to the queue
7. It "pops" the first ite= m on the queue and repeats the algorithm

*There reason why it is a s= et is because there is no need to check for circular dependencies in overla= ys.

Once the algorithm is finished it would print out something lik= e this

foo overlay (the one the user wants to add) depends on bar ov= erlay.
Would you like to add bar as well? Y/N

If yes:
bar over= lay depends on biz overlay.
Would you like to add biz as well? Y/N
And so on

------

PROS: Fairly simple algorithm.
CONS: U= nwanted overlays with packages the user will never use.

The main con= is that even though the overlay is marked as "dependency", not *= all* packages depend on the other overlays: Only a few.
Having said= that, this can be mitigated with only minimal manual intervention by the u= ser.

I would love to get feedback on this ide= a and what are some of its shortcomings/things that I missed/haven't co= nsidered yet.
Thanks in advance and thank you for making gentoo s= o great.

Have a good day

= - Tomas Fabrizio Orsi a.k.a Lima Limon

--0000000000001b842b05fe6d6c85--