>
> 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.

As a matter of fact, Michał Górny raised the same questions:
"A bit of a problem is how to design UI in eselect-repository. I'm not 100%
sure
that having it automatically install dependent repositories without
confirmation is a good idea"
(
https://github.com/projg2/eselect-repository/issues/20#issuecomment-1579288719)

Ideally, confirmation would be asked before proceeding to sync the other
overlays.
I agree that doing something without the user's knowledge is not ideal.

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.


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?

Best regards,
- Tomas Fabrizio Orsi

El mié, 21 jun 2023 a las 12:57, Mike Gilbert (<floppym@gentoo.org>)
escribió:

> On Wed, Jun 21, 2023 at 11:41 AM Florian Schmaus <flow@gentoo.org> wrote:
> >
> > On 20.06.23 19:26, Mike Gilbert wrote:
> > > On Tue, Jun 20, 2023 at 1:08 PM Florian Schmaus <flow@gentoo.org>
> 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ł Górny pointed the same thing out.
> > >>> However, Michał also added, quote: "What's really lacking here is
> > >>> support for specifying dependencies via |repositories.xml|
> > >>
> > >> Do we need to duplicate the information in repositories.xml, with all
> > >> 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 recursively?
> > >
> > > That would be a significant change in behavior for eselect repository.
> >
> > 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.
> 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.
>
>