Refine documentation about externally maintained and unmaintained linux packages. #12507
Conversation
|
If we agree to remove this, we should also remove it from the "installing the solidity compiler" docs. |
docs/installing-solidity.rst
Outdated
| The ``solc`` snap uses strict confinement. This is the most secure mode for snap packages | ||
| but it comes with limitations, like accessing only the files in your ``/home`` and ``/media`` directories. | ||
| For more information, go to `Demystifying Snap Confinement <https://snapcraft.io/blog/demystifying-snap-confinement>`_. | ||
|
|
||
| Arch Linux also has packages, albeit limited to the latest development version: |
There was a problem hiding this comment.
Actually, I also think we should make it clear that we don't maintain the Archlinux and Gentoo ones ourselves...
|
Pinging @ElOpio so that he can chime in. From #11940 looks like the current problem is not that it's broken (it's now up to date in the I agree that it looks like having package configuration not maintained by us in the repo did not turn out great and is likely not the way forward for other packages. But in case snap in particular it looks like things are getting under control and it'll start working with 0.8.12 so I wouldn't throw it away now. I'd vote for keeping it as long as it stays actively maintained by @ElOpio.
From the original PR that added it (#2475 (comment)):
|
|
Alright then, we can wait and if it works out again keep it in here. Closing this for the time being then. |
|
We should probably still mention in the docs that the snap, archlinux and gentoo packages are externally maintained. |
|
I'm not using solidity or snapcraft on my job anymore, so being an active maintainer sounds a little far from my current interests. I still like both projects so I can take a look every now at the automated pipelines and then and check if things get stuck. I won't spend a lot of time testing this though. If you don't want to maintain it, instead of "externally maintained" I would call it "unmaintained". "Maintained by the robot uprising syndicate" :) |
|
I think it would be a waste to just drop this completely. Maybe we could encourage some people from the community to step in and help maintain this? I mean, it does not necessarily have to sit inside the main repo but would still nice to have it somewhere. People clearly want these packages and work on snap one is mostly done. This situation looks a bit like the one with translations where we do have some people willing to contribute but not enough so quality is a bit lacking. We could create a separate repo (or a whole org though that might be an overkill) for third-party packages and set up some rules on contribution. Then promote it a bit and only consider a package official if it reaches some level of quality and has at least two active maintainers. @franzihei What's your opinion on this? Do you think it would be worth the effort? |
|
As discussed in the chat, I think it's best to for now, not remove it entirely yet but rather say it's "unmaintained" and also add the info to relevant others (e.g. Arch) that they are externally maintained (if they are). Then, if nobody shows interest in snap in the coming months we can still consider removing it from the docs completely. If it's the other way around and it turns out people have interest we can try to help find/coordinate external maintainers. |
ekpyron
changed the title
Makes sense. |
Maybe not uncontroversial, but:
I don't think we should have this in the repo, if none of us actively maintains it and the external support cycle is as long as it seems to be. Is there a particular reason why this has to be in our repo? Can't people still maintain snap packages externally, if they want to, without having this in our repo?