> > 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 (<flop...@gentoo.org>) escribió: > On Wed, Jun 21, 2023 at 11:41 AM Florian Schmaus <f...@gentoo.org> wrote: > > > > On 20.06.23 19:26, Mike Gilbert wrote: > > > On Tue, Jun 20, 2023 at 1:08 PM Florian Schmaus <f...@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. > >
