| 1 |
Hi Nils, thanks for your interest. |
| 2 |
|
| 3 |
> First of, it seems that this daemon will run on a privileged machine that is |
| 4 |
> capable of uploading files into the gentoo infrastructure, but it also has |
| 5 |
> to deal with no official ebuilds. This does seem rather paradoxical to me. |
| 6 |
> Or is it located on the users machine, and then only downloads these |
| 7 |
> snapshots? |
| 8 |
|
| 9 |
The proposal states that unprivileged ebuilds will not be served by |
| 10 |
the infrastructure. What this means is that the daemon will scan the |
| 11 |
main tree repo and registered overlays (those in Layman and/or on |
| 12 |
overlays.gentoo.org) for ebuilds using its eclass/format. Unofficial |
| 13 |
ebuilds (those not uploaded to the above locations) are excluded in |
| 14 |
the sense that the daemon never sees them. The eclass would be |
| 15 |
responsible for making unofficial ebuilds behave like live ebuilds. |
| 16 |
|
| 17 |
> Secondly, I understand this as a way to have a mirror periodically check the |
| 18 |
> upstream repository for changed, and then respond by notifying the |
| 19 |
> maintainer. Ebuilds will be left using these snapshots, which seems like a |
| 20 |
> rather small improvement over the current system. |
| 21 |
|
| 22 |
Yes, that's the way it should work. The whole idea of snapshots is to |
| 23 |
provide stability. If the upstream repo changed, the maintainer needs |
| 24 |
to go and see what changed and how that will affect the package. It |
| 25 |
might seem like a small step, but for projects that never produce |
| 26 |
official source snapshots, it's a big step to me. |
| 27 |
|
| 28 |
> Or is this a system where the daemon sits in the in the infrastructure and |
| 29 |
> creates the snapshot automatically once an ebuild is provided, and maybe |
| 30 |
> even then automatically creates new versioned snapshots and ebuilds based on |
| 31 |
> the new versions of the source code, and places these on the master mirror |
| 32 |
> to be distributed. Maybe with some sort of maintainer having to sign of on |
| 33 |
> the new version though? |
| 34 |
|
| 35 |
You could experiment with that, but the first step is to make a daemon |
| 36 |
that reacts only to new ebuilds that "ask" for snapshots, for the |
| 37 |
reasons I mentioned above. |
| 38 |
|
| 39 |
> And thirdly, there is currently no mentor for this project. Would anyone be |
| 40 |
> interested in working with me on this? |
| 41 |
|
| 42 |
You'll have to spam the infra team to see if anyone is interested. I |
| 43 |
can clarify the details but I'm not sure if I can serve as a mentor |
| 44 |
for this... maybe if nobody responds to my collision checking project |
| 45 |
idea. |
| 46 |
|
| 47 |
-ak |
Archives