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 E9408158009 for ; Wed, 21 Jun 2023 14:13:36 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id EC973E08F5; Wed, 21 Jun 2023 14:13:32 +0000 (UTC) Received: from mail-oi1-x236.google.com (mail-oi1-x236.google.com [IPv6:2607:f8b0:4864:20::236]) (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 C0159E0884 for ; Wed, 21 Jun 2023 14:13:32 +0000 (UTC) Received: by mail-oi1-x236.google.com with SMTP id 5614622812f47-39bcba263efso4723571b6e.1 for ; Wed, 21 Jun 2023 07:13:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fi-uba-ar.20221208.gappssmtp.com; s=20221208; t=1687356811; x=1689948811; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :from:to:cc:subject:date:message-id:reply-to; bh=EJ8vKWwO+qdp9uozEfdy483hO8356T6In/y1ZiszNcQ=; b=zb/3+vPksjogHS87XHYnn5EHLmRVUf5nYV8QyO5+qFHYDmhZrbLb8nOdF/rq3VCQuR Mfb4ZvMg/DLiqjUPA8ssOXMJ5Kux0jn3CVJ/Kkj71uREFPrgIcN4DUhd6wNBlDntnYHj u16jZ68PxbWweJ5qZLoewIXgsd/61TrIdShqbJB67FKGldc+AOmblcORcwArcNJdeHsj VVqkPtNnI2xpBNrpzJhM9n4fYH9zQRamy5xOgRAo0OY1OHVc6D9sPlR8Ig1cW2QHhXoS ZFDu7PitV1+6ZEalypsyzVVhDzuJrm0cbZxWbGw7GKvadHimL4Be8GxqPlAmPoVtPZVX Dw7g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1687356811; x=1689948811; 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=EJ8vKWwO+qdp9uozEfdy483hO8356T6In/y1ZiszNcQ=; b=Fg+EbM/kPj2OtYMv6zSDOeehcgzmaQATQFcpxluYY02BBBb5Fib6KWmyBFTf3dZyZG mlo977siY8Ey4mWL1w3VwGSepHtkMqTtChjl38Vg2Rek/EPprjesYYXHPEFNzf5AamK4 Gl5e7dZ9z7i8sWym0GvzMrRmhi53Ox+PKY95puGhXQ7UVsu9TBiMXSWek2LdbO8aUYcq QcIoO/V0RWGdZdD+PEWgxTnS8Ocx59Zb6rSo4QV5q+L2LIhZ0mgtYANAtx4BTJLg446N cwlpflflWWBHz2FVZxvMXe9rA+D9Xp1TqTlH2gNP4GJ/ozwkOqiDrRhDs0sWMzhmTFO9 rEog== X-Gm-Message-State: AC+VfDzi1tYY6gi3ImRz6BJpufZh6wByfcLGtQVZGyyalTzqXAmzLV27 bX/73KnTwfEXLkqPVYVjktjyf/ONmPOLYwqfgeC5FXzXfXsOxupgRuRnGg== X-Google-Smtp-Source: ACHHUZ5O/vHnlA0c3pcLP5RUuNz6s2GsLaIlrb/oXGkWG8BTUrqFNdOWdcrF4skCXQeALY9xdBqYFb3Ng825/MykMEk= X-Received: by 2002:a05:6808:1529:b0:3a0:3666:6368 with SMTP id u41-20020a056808152900b003a036666368mr3570417oiw.4.1687356811523; Wed, 21 Jun 2023 07:13:31 -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> <06d53584-9c50-b819-cac5-abc17249c515@gentoo.org> <0b36b5e7-bb3f-2166-bb16-2fef8f35fde6@gentoo.org> <92ac9bbb-7c82-115d-fd70-298ef39ef5a7@gentoo.org> In-Reply-To: <92ac9bbb-7c82-115d-fd70-298ef39ef5a7@gentoo.org> From: TOMAS FABRIZIO ORSI Date: Wed, 21 Jun 2023 11:12:55 -0300 Message-ID: Subject: Re: [gentoo-dev] Eselect repository feature request To: gentoo-dev@lists.gentoo.org Content-Type: multipart/alternative; boundary="0000000000005c559405fea45f5e" X-Archives-Salt: 09433743-93f9-46f8-ad3d-598d0e8c3050 X-Archives-Hash: ab4206f90f1161509aa156583140ddf2 --0000000000005c559405fea45f5e Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable > > I just checked the internal overlays team guide[1] and it does > explicitly say that repo_name should match the repositories.xml . Oh, great news then. Thanks for checking. Also thank you overlays team! That being said it is possible for the > owner to change repo_name and (accidentally) not update > repositories.xml. These cases should be fixed but exactly how would have > to be determined on a case by case basis. > That is true, however I think those are "edge" cases. Furthermore, how often do people change their overlay's name? I legitimately do not know. In any case, this is just something to keep in mind when writing this > check. It is not fully guaranteed that eselect repository can find the > repository that is requested in some master=3D entry. > Great point. Btw, in your opinion, do you think having this emerge --sync + eselect repository feature is doable? Best regards, - Tomas Fabrizio Orsi El mi=C3=A9, 21 jun 2023 a las 10:58, Andrew Ammerlaan (< andrewammerlaan@gentoo.org>) escribi=C3=B3: > On 21/06/2023 15:40, TOMAS FABRIZIO ORSI wrote: > > What I meant is that emerge --sync/eix --sync does this check > > instead of > > eselect repository. To me this makes sense since we can only do thi= s > > check *after* syncing. > > > > That is a great point; I had not considered it. > > So, you are saying to have emerge --sync/eix --sync check the masters > > key and then warn the user of not synced up overlays, correct? > > Yes > > > This however would require > > that profiles/repo_name is always equal to the name entry in > > repositories.xml, I'm not sure if this is currently always the case= . > > > > I had not considered this possibility either. > > If that's the case, then I believe there are to possible behaviors: > > If the names do match, then emerge --sync/eix --sync could both: > > 1. issue a warning of the missing overlay dependency > > 2. run the command to add said overlay (with confirmation). > > On the other hand, if the names do not match, a missing dependency > warning > > could be issued, skipping the second step. > > This sounds to me to be fairly reasonable behaviour. > > > > In the cases where the names do not match; what could be the best > > solution to "fix" this? Change repositories.xml on a case by case basis= ? > > Ask overlay owners to change their profiles/repo_name and > > profiles/masters key? Neither? > > I just checked the internal overlays team guide[1] and it does > explicitly say that repo_name should match the repositories.xml . > So probably there is no problem. That being said it is possible for the > owner to change repo_name and (accidentally) not update > repositories.xml. These cases should be fixed but exactly how would have > to be determined on a case by case basis. > > In any case, this is just something to keep in mind when writing this > check. It is not fully guaranteed that eselect repository can find the > repository that is requested in some master=3D entry. > > Best regards, > Andrew > > [1] > https://wiki.gentoo.org/wiki/Project:Overlays/Internal_Overlays_team_guid= e > > > --0000000000005c559405fea45f5e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I just c= hecked the internal overlays team guide[1] and it does
explicitly say that repo_name should match the repositories.xml <name>= ;.
Oh, great news then. Thanks for checking. Also thank y= ou overlays team!

That being said it is possible for the
owner to change repo_name and (accidentally) not update
repositories.xml. These cases should be fixed but exactly how would have to be determined on a case by case basis.
That is t= rue, however I think those are "edge" cases. Furthermore, how oft= en do
people change their overlay's name? I legitimately do n= ot know.

In any case, this is just something to keep in mind when wr= iting this
check. It is not fully guaranteed that eselect repository can find the
repository that is requested in some master=3D entry.
Great point.
Btw, in your opinion, do you think having thi= s emerge --sync + eselect repository feature is doable?

Best regards,
- Tomas Fabriz= io Orsi


El mi=C3=A9, 21 jun 2023 a las 10= :58, Andrew Ammerlaan (<an= drewammerlaan@gentoo.org>) escribi=C3=B3:
On 21/06/2023 15:40, TOMAS FABRIZIO ORSI w= rote:
>=C2=A0 =C2=A0 =C2=A0What I meant is that emerge --sync/eix --sync does = this check
>=C2=A0 =C2=A0 =C2=A0instead of
>=C2=A0 =C2=A0 =C2=A0eselect repository. To me this makes sense since we= can only do this
>=C2=A0 =C2=A0 =C2=A0check *after* syncing.
>
> That is a great point; I had not considered it.
> So, you are saying to have emerge --sync/eix --sync check the masters<= br> > key and then warn the user of not synced up overlays, correct?

Yes

>=C2=A0 =C2=A0 =C2=A0This however would require
>=C2=A0 =C2=A0 =C2=A0that profiles/repo_name is always equal to the name= entry in
>=C2=A0 =C2=A0 =C2=A0repositories.xml, I'm not sure if this is curre= ntly always the case.
>
> I had not considered this possibility either.
> If that's the case, then I believe there are to possible behaviors= :
> If the names do match, then emerge --sync/eix --sync could both:
>=C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0 1. issue a warning of the missing overl= ay dependency
>=C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0 2. run the command to add said overlay = (with confirmation).
> On the other hand, if the names do not match, a missing dependency war= ning
> could be issued, skipping the second step.
> This sounds to me to be fairly reasonable behaviour.
>
> In the cases where the names do not match; what could be the best
> solution to "fix" this? Change repositories.xml on a case by= case basis?
> Ask overlay owners to change their profiles/repo_name and
> profiles/masters key? Neither?

I just checked the internal overlays team guide[1] and it does
explicitly say that repo_name should match the repositories.xml <name>= ;.
So probably there is no problem. That being said it is possible for the owner to change repo_name and (accidentally) not update
repositories.xml. These cases should be fixed but exactly how would have to be determined on a case by case basis.

In any case, this is just something to keep in mind when writing this
check. It is not fully guaranteed that eselect repository can find the
repository that is requested in some master=3D entry.

Best regards,
Andrew

[1]
https://wiki.gentoo.org/wi= ki/Project:Overlays/Internal_Overlays_team_guide


--0000000000005c559405fea45f5e--