Isn't that duplicating the information of metadata/layout.conf's
'master' key-value pair [1]?
On 18.06.23 22:39, TOMAS FABRIZIO ORSI wrote:
Hello gentoo devs. The other day I made a feature suggestion to the
eselect repository github page. (Here's the link: https://github.com/projg2/eselect-repository/issues/20 <https://github.com/projg2/eselect-repository/issues/20>).
Michał Górny suggested that I should contact the gentoo-dev mailing list with my suggestion, so here it is: My suggestion is to make it possible
for eselect repository to manage overlay dependencies.
As it stands, and as far as I'm concerned, there is no "proper" way of having an ebuild dependency from another overlay. So overlay writers
have to copy ebuilds from other overlays or rewrite them. This implies synchronization issues (where the "copied" ebuilds get out of sync from
the original ebuild) and time loss (people writing the same ebuild more than once).
Michał Górny suggested that I should make an edit to the
repositories.xml file in order to tackle the issue.
This is my general idea:
(I am using the github template as an example, but the idea should apply
to all other templates. I got this file from
https://github.com/gentoo/api-gentoo-org/blob/master/files/overlays/repositories.xml
< https://github.com/gentoo/api-gentoo-org/blob/master/files/overlays/repositories.xml
).
* GITHUB TEMPLATE
<repo quality="experimental" status="unofficial">
<name>XXXXX</name>
<description lang="en">XXXXXX</description>
<homepage>https://github.com/XXXX/xxxx <https://github.com/XXXX/xxxx></homepage>
<owner type="person">
<email>XXXXX</email>
<name>XXXXX</name>
</owner>
<source type="git">https://github.com/XXXX/xxxx.git <https://github.com/XXXX/xxxx.git></source>
<source type="git">git+ssh://git@github.com/XXXX/xxxx.git <http://git@github.com/XXXX/xxxx.git></source>
<feed>https://github.com/XXXX/xxxx/commits/master.atom <https://github.com/XXXX/xxxx/commits/master.atom></feed>
<dependencies>
<name>overlayName</name>
</dependencies>
</repo>
Isn't that duplicating the information of metadata/layout.conf's
'master' key-value pair [1]?
- Flow
1: https://wiki.gentoo.org/wiki/Repository_format/metadata/layout.conf#masters
<div><span><span style="max-width:230px"> However, </span></span><span><span style="max-width:230px">Michał also added, quote: </span></span>"What's really lacking here is support for specifying dependencies via <code>repositories.xml</code>. Once such a thing is implemented, We can look into having eselect-repository handle that once it's specified." (Here's the link to the conversation: <a href="https://github.com/projg2/eselect-repository/issues/20#issuecomment-1579098528"
<div>- Tomas Fabrizio Orsi<br></div><div><br></div><div><br></div><div class="gmail_quote"><div dir="ltr" class="gmail_attr">El mar, 20 jun 2023 a las 10:44, Florian Schmaus (<<a href="mailto:flow@gentoo.org" target="_blank">flow@gentoo.org</a>>) escribió:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 18.06.23 22:39, TOMAS FABRIZIO ORSI wrote:<br>
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. Currently, it does not actually sync any repos; it just manages the
config in /etc/portage/repos.conf.
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?
On 20/06/2023 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. Currently, it does not actually sync any repos; it just manages the
config in /etc/portage/repos.conf.
Or maybe we just output a warning after syncing if a repository listed
in masters= is not enabled? Less automated, but simpler. I don't think
this situation happens very often so this is probably good enough IMO.
Best regards,
Andrew
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.
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?
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 profiles/repo_name is always equal to the name entry in repositories.xml, I'm not sure if this is currently always the case.
On 21/06/2023 04:17, TOMAS FABRIZIO ORSI wrote:
A warning could be a great way of making the user aware of thissituation.
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
<div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">This however would require <br>that profiles/repo_name is always equal to the name entry in <br> repositories.xml, I'm not sure if this is currently always the case.</blockquote><div>I had not considered this possibility either. <br></div><div>If that's the case, then I believe there are to possible behaviors:<br>If the names do match, then
In any case, this is just something to keep in mind when writing this
check. It is not fully guaranteed that eselect repository can find the
repository that is requested in some master= entry.
Great point.
Btw, in your opinion, do you think having this emerge --sync + eselect repository feature is doable?
Sure, I think it could work.
On 21/06/2023 16:12, TOMAS FABRIZIO ORSI wrote:
In any case, this is just something to keep in mind when writing thisthe
check. It is not fully guaranteed that eselect repository can find
repository that is requested in some master= entry.
Great point.
Btw, in your opinion, do you think having this emerge --sync + eselect repository feature is doable?
Sure, I think it could work.
Best regards,
Andrew
Sure, I think it could work.
Great to hear.
In that case I could try to give it a try and make a pull request to the emerge --sync with a basic idea.
Any tips?
I just checked the internal overlays team guide[1] and it does
explicitly say that repo_name should match the repositories.xml <name>.
owner to change repo_name and (accidentally) not update
repositories.xml. These cases should be fixed but exactly how would have
to be determined on a case by case basis.
check. It is not fully guaranteed that eselect repository can find the repository that is requested in some master= entry.
On 21/06/2023 15:40, TOMAS FABRIZIO ORSI wrote:
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?
Yes
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.warning
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
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?
I just checked the internal overlays team guide[1] and it does
explicitly say that repo_name should match the repositories.xml <name>.
So probably there is no problem. That being said it is possible for the
owner to change repo_name and (accidentally) not update
repositories.xml. These cases should be fixed but exactly how would have
to be determined on a case by case basis.
In any case, this is just something to keep in mind when writing this
check. It is not fully guaranteed that eselect repository can find the repository that is requested in some master= entry.
Best regards,
Andrew
[1] https://wiki.gentoo.org/wiki/Project:Overlays/Internal_Overlays_team_guide
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>In any case, this is just something to keep in mind when writing this <br>check. It is not fully guaranteed that eselect repository can find the <br> repository that is requested in some master= entry.</div></blockquote><div>Great point. <br></div><div>Btw, in your opinion, do you think having this emerge --sync + eselect repository feature is doable?</div><div><br></div><div><span class="gmail-im"><
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?
$ sudo emerge --sync
Unavailable repository 'foo' referenced by masters entry in '/var/db/repos/gentoo/metadata/layout.conf'
On Wed, Jun 21, 2023 at 10:43 AM TOMAS FABRIZIO ORSI <torsi@fi.uba.ar> wrote:
Sure, I think it could work.
Great to hear.emerge --sync with a basic idea.
In that case I could try to give it a try and make a pull request to the
Any tips?
So emerge already emits a warning message when a repo is missing:
https://gitweb.gentoo.org/proj/portage.git/tree/lib/portage/repository/config.py?h=portage-3.0.48.1#n1070
That looks something like this:
$ sudo emerge --sync
Unavailable repository 'foo' referenced by masters entry in '/var/db/repos/gentoo/metadata/layout.conf'
<br>
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.
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.
On Wed, Jun 21, 2023 at 11:41 AM Florian Schmaus <flow@gentoo.org> wrote:
On 20.06.23 19:26, Mike Gilbert wrote:wrote:
On Tue, Jun 20, 2023 at 1:08 PM Florian Schmaus <flow@gentoo.org>
matter
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
'masters'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
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.
> wrote:<br>><br>
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?
I think flow's idea to make the sync command configurable somehow
would be sufficient, assuming there is demand for it.
On 21/06/2023 17.56, Mike Gilbert wrote:
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:
That would be a significant change in behavior for eselect repository.
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? >>>
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.
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.
I think flow's idea to make the sync command configurable somehow
would be sufficient, assuming there is demand for it.
like unnecessary extra abstraction.
On Wed, Jun 21, 2023 at 12:47 PM TOMAS FABRIZIO ORSI <torsi@fi.uba.ar> wrote:
I had not considered that possibility either. In that case, could notthe overlay
dependency resolution be handled as a module?manager/sync program basis?
Said module could be a common interface for different package managers. Then, the execution of said module would be handled on a per package
I'm not quite certain what you mean by "module" here, but that sounds
like unnecessary extra abstraction.
I think flow's idea to make the sync command configurable somehow
would be sufficient, assuming there is demand for it.
[[PGP Signed Part:Undecided]]
On 21/06/2023 17.56, Mike Gilbert wrote:
On Wed, Jun 21, 2023 at 11:41 AM Florian Schmaus <flow@gentoo.org> wrote: >>>
On 20.06.23 19:26, Mike Gilbert wrote:I can't speak for "upstream", but here are my concerns:
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:That would be a significant change in behavior for eselect repository.
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? >>>>
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?
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.
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.
2. Add a way to use the "real" upstream sources instead of our mirrored
ones
Florian Schmaus <flow@gentoo.org> writes:
[[PGP Signed Part:Undecided]]metadata/layout.conf's
On 21/06/2023 17.56, Mike Gilbert wrote:
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
I can't speak for "upstream", but here are my concerns:Right, but it seems to be a desirable behaviour. Cases where the userThat would be a significant change in behavior for eselect repository. >>>'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? >>>>
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?
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.
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.
While looking at this, it might be worth evaluating 2 other things
which users have mentioned during the migration away from layman:
1. Adding a way to fully disable the cache fetching;
2. Add a way to use the "real" upstream sources instead of our mirrored
ones
best,
sam
2. Add a way to use the "real" upstream sources instead of our mirrored
ones
Isn't this eselect repository's default behaviour? Or am I misunderstanding? When I run "eselect repository list" I get the source repositories, not the mirrored ones.
Is it using the mirrored one behind the scenes?
Best regards,
- Tomas Fabrizio Orsi
El mié, 21 jun 2023 a las 15:44, Sam James (<sam@gentoo.org>) escribió:
Florian Schmaus <flow@gentoo.org> writes:
[[PGP Signed Part:Undecided]]
On 21/06/2023 17.56, Mike Gilbert wrote:
On Wed, Jun 21, 2023 at 11:41 AM Florian Schmaus <flow@gentoo.org> wrote:
I can't speak for "upstream", but here are my concerns:
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?
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.
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.
While looking at this, it might be worth evaluating 2 other things
which users have mentioned during the migration away from layman:
1. Adding a way to fully disable the cache fetching;
2. Add a way to use the "real" upstream sources instead of our mirrored
ones
best,
sam
</div><div>Here's the repo: <a href="https://github.com/lima-limon-inc/OverlayStats">https://github.com/lima-limon-inc/OverlayStats</a></div><div>(it also contains information regarding package amounts by overlay, <br></div><div>which I found itquite interesting)</div><div>And here's a google sheet with the data loaded in:Â </div><div><a href="https://docs.google.com/spreadsheets/d/1Spti8KCFQbi0kszvgBnxMtAlUC3RU1HZU8MZHlYP5xQ/edit?usp=sharing">https://docs.google.com/spreadsheets/d/
<div><div>Best regards,</div><div>- Tomas Fabrizio Orsi</div></div></div><div></div></div>
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 546 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 31:19:25 |
| Calls: | 10,391 |
| Calls today: | 2 |
| Files: | 14,064 |
| Messages: | 6,417,107 |