My biggest concern about this idea of “merging everything into the
snapd repo” is that it’s just going to mask the lack of activity to all of these things. Moving
snapd-xdg-open into the
snapd repo will not make it better maintained.
The SELinux module was merged into snapd in the hopes that when Snappy developers actually change things, they’d fix the policy at the same time (like they do for AppArmor profiles). That obviously does not happen. Some of this is because it’s not packaged or used anywhere yet, but it’s not particularly hard to add a line for a new executable or delete one when it goes away. Will this get better now that Fedora has snapd builds that work? I don’t know, but I’m not holding my breath. I personally suspect that I will wind up doing everything alone until someone adds SELinux module packaging to the Debian and Ubuntu packages, because then someone else will have to care. With that kind of weight, why should have I bothered to merge it into the snapd repo?
I strongly suspect it’ll be exactly the same for
snapd-xdg-open. For the most part, it is for
snap-confine. It is almost exclusively worked on by @zyga-snapd alone. There were virtually no maintainability benefits to merging everything into snapd. If anything, it’s now harder to fix things in mainline because now we have to wait for someone to care to review the PR and merge it.
At first, I was for merging
snap-confine into snapd, but as I watched the development and interacted with you guys, I became increasingly against it, because the whole process has too much friction and snapd alone is too complex to review. By the time the proposal to merge it came in, I was against it because it became clear to me that it’s not actually going to provide any material benefits. So far, from my point of view, I believe we haven’t gained anything from merging snap-confine into snapd, and if anything, it’s now more difficult to be agile. @zyga-snapd and I made more progress on snap-confine in Fedora when it was separate than when it was merged into snapd.
But frankly, I’m starting to not care one way or the other anymore, since apparently we want to have a monorepo. At least from the Fedora perspective, I’m likely to just maintain each component as subpackages unless there’s a good reason not to. That gives me the flexibility to easily deal with it being broken back out when it becomes unsustainable as a monorepo.
At least specifically in regards to
snapd-xdg-open, the namespaces of the services should be changed as part of the merge from
io.snapcraft.*. It should have happened when it was first put up on GitHub. I did file an issue about it several months ago, and brought it up in person even earlier. The fact nothing happened despite me bringing up twice in a short span of time is damning.