Re: [gentoo-dev] Eselect repository feature request

[Florian Schmaus]

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?

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.



- Flow

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.

OpenPGP_0x8CAC2A9678548E35.asc
Description: OpenPGP public key

OpenPGP_signature
Description: OpenPGP digital signature