On Wed, Jun 21, 2023 at 12:49 PM Florian Schmaus <f...@gentoo.org> wrote: > > On 21/06/2023 17.56, Mike Gilbert wrote: > > 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. > > Would an opt-out switch be enough to alleviate those concerns of you?
Yes. > > > 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. > > Those two points seem to be based on the same fundamental concern. > > The only portage specific code would be the call to "emaint sync -r > $repo" (remember that "emerge --sync" is just a wrapper for "emaint sync > --auto"). I think it would be easy to add later 1. add support for > different package managers (if the need arises), and 2. make the "sync > command" user configurable. Sure, that seems sensible.
