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 B2A7F158009 for ; Wed, 21 Jun 2023 13:40:47 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 5D919E0871; Wed, 21 Jun 2023 13:40:43 +0000 (UTC) Received: from mail-oo1-xc2c.google.com (mail-oo1-xc2c.google.com [IPv6:2607:f8b0:4864:20::c2c]) (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 2821AE0849 for ; Wed, 21 Jun 2023 13:40:40 +0000 (UTC) Received: by mail-oo1-xc2c.google.com with SMTP id 006d021491bc7-55e11f94817so3566802eaf.2 for ; Wed, 21 Jun 2023 06:40:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fi-uba-ar.20221208.gappssmtp.com; s=20221208; t=1687354839; x=1689946839; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :from:to:cc:subject:date:message-id:reply-to; bh=YTAAusghNgYAZPfnZhoZ/Qby6dPUuWNJPAKIDlf09Rk=; b=JCLLQtq3hXGu4k458XAhfdh857x4HgVAKM/Ca+hK+pbrtK7DJNR1teT2KjRWM33DKh 4VSaj3oIaFVUhDPOat27CA6/GDmhnZNlQ60h7E1ckJ5L+BFU/h4Vr5p1emUKF5W5tfgH 9zKcVj2wm+1810k+RN55oGTEUMYJIUVzmA9vzIjTeQzqZBmpDcfiwWZqpewjIGSeQx/n To2rMTUPtJ4DsdoAaZzBgRb4VQpdHmyFOwHXTfyORnCdDjK7j2zlbtKPDlcRh9rDfHin qYqC3O6qBoDtvvZ98M3RKL62cccvcNn6qw5lH1W8cRVH6jHDaXgVaRRre3R/NbmKy4oI p2ow== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1687354839; x=1689946839; 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=YTAAusghNgYAZPfnZhoZ/Qby6dPUuWNJPAKIDlf09Rk=; b=VqJwJEAvK4I2Re+BNHRzb2M9i59wLA7gRUufqrY42HZ6+ljsyPTBaCURPH75GPliAl sKxqeAFnONseQEeguq1/mYJf+ZHEgfl0EVLYmVVeuZyjDNC4ZzTXWIYQVxJrr1F5tup+ lBGOcDw6KRSL2LRwXFVqXEY+iEISXY/vg53C/Qv4V0SD8iuMHyNwyEa1s5pRU82XT8Tn NPhwNJdV2rI6s2wSRbQEi2DpO934/fJZVrapzYfeA4HwwbOZaKbjb+4yHzmIbUzNmBcW mIdU2AQ+wnJvX9GTUL81DGYF0SliqrKYrcHqyZmGlLEeOrTIK1y/gAYJsWeyU8Em02G7 03Hw== X-Gm-Message-State: AC+VfDwI2NIINoZPm4a4Huek5IG57GOytbX47PylWHvrVxEbcYxPo6MT +HUK1mH7T15WqVmeoyyVrkIDyCvFB4oev3RKMa7QhmG+7A+YsIvdGbN1zQ== X-Google-Smtp-Source: ACHHUZ7hGqYShbv7EeSY8c8pbTrE/jHe4yLl8J5w02sNShTCx7rqzwBsZcK4vBo6O2eXcpHbb/T1F5TxvZ2mOmMEiPI= X-Received: by 2002:a4a:c442:0:b0:560:a9b2:d24e with SMTP id h2-20020a4ac442000000b00560a9b2d24emr1644365ooq.4.1687354839383; Wed, 21 Jun 2023 06:40:39 -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> In-Reply-To: <0b36b5e7-bb3f-2166-bb16-2fef8f35fde6@gentoo.org> From: TOMAS FABRIZIO ORSI Date: Wed, 21 Jun 2023 10:40:03 -0300 Message-ID: Subject: Re: [gentoo-dev] Eselect repository feature request To: gentoo-dev@lists.gentoo.org Content-Type: multipart/alternative; boundary="000000000000cfcf2305fea3e960" X-Archives-Salt: 7d5aa139-29b2-47ef-bef4-9236b3dd5441 X-Archives-Hash: 12a7aed5483f302a58f0a80368c42cd5 --000000000000cfcf2305fea3e960 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable > > 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 this > 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? 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? Best regards, - Tomas Fabrizio Orsi El mi=C3=A9, 21 jun 2023 a las 4:15, Andrew Ammerlaan (< andrewammerlaan@gentoo.org>) escribi=C3=B3: > On 21/06/2023 04:17, TOMAS FABRIZIO ORSI wrote: > > A warning could be a great way of making the user aware of this > situation. > > Having said that, if eselect repository is able to check and warn the > > user of a not synced overlay(ies) dependency, then the hard bit is done > > 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 this > check *after* syncing. Plus the user can also make changes to repos.conf > without using eselect repository, having the check done post-syncing > covers these cases as well. > > You're probably right that once we have some message that says "Warning: > {repo1} is missing, it is required by {repo2}" it should be trivial to > call 'eselect repository enable {repo1}'. 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. > > Best regards, > Andrew > > > --000000000000cfcf2305fea3e960 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
What I m= eant is that emerge --sync/eix --sync does this check instead of
eselect repository. To me this makes sense since we can only do this
check *after* syncing.
That is a great point; I had not c= onsidered it.
So, you are saying to have emerge --sync/eix -= -sync check the masters
key and then warn the user of not sy= nced up overlays, correct?

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:
=C2= =A0=C2=A0=C2=A0=C2=A0 1. issue a warning of the missing overlay dependency =
=C2=A0=C2=A0=C2=A0=C2=A0 2. run the command to add said overlay (with c= onfirmation).
On the other hand, if the names do not match, a mis= sing 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 cou= ld be the best
solution to "fix" this? Change repo= sitories.xml on a case by case basis?
Ask overlay owners to c= hange their profiles/repo_name and
profiles/masters key? Neither?=

Best regards,
- Tomas Fabr= izio Orsi

El mi=C3=A9, 21 jun 2023 a las 4:15, Andrew Ammerlaan (<= andrewammerlaan@gentoo.org>) escribi=C3=B3:
On 21/06/2023 04:17, TOMAS FABRIZIO ORSI wrote:
> A warning could be a great way of making the user aware of this situat= ion.
> Having said that, if eselect repository is able to check and warn the =
> user of a not synced overlay(ies) dependency, then the hard bit is don= e

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 this
check *after* syncing. Plus the user can also make changes to repos.conf without using eselect repository, having the check done post-syncing
covers these cases as well.

You're probably right that once we have some message that says "Wa= rning:
{repo1} is missing, it is required by {repo2}" it should be trivial to=
call 'eselect repository enable {repo1}'. This however would requir= e
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.
Best regards,
Andrew


--000000000000cfcf2305fea3e960--