Conversation
Has been failing to build for 5 months. It doesn't seem to be useful on its own, but only in conjunction with other packages, which are not in Nixpkgs.
|
If you're wondering what LUCI is, here's the blurb:
It's sort of public, sort of private, and is extremely Google-centric. Neat software, just not packaged for Nix yet... and I suspect never will be unless someone actually uses it outside of the Googleplex. |
A fixed build has been provided within 24 hours of the maintainer being notified of the build failure.
It contains tools that are useful for building software developed at Google, especially around Chromium. Google software does get packaged in
Keeping it in Furthermore, it may already be useful for those concerned in supply chain security. For example, the package provides
Slightly OT, but is there a process for donating build capacities? Anyway, if the package is perceived as being too big, a less destructive alternative might be to identify parts which are not useful for packaging outside of Google, and trim down the package a bit. In conclusion, I propose not to drop the package. As someone who repeatedly worked on getting software to run without resorting to binary blobs using |
A lot of software shares this kind of genesis, e.g. look at |
To be clear the suggestion to drop is not "because it fails to build", but because "it seems to be unused". The "it failed to build for 5 months without anyone noticing" is merely a proxy to be able to tell "well, it probably is unused". Even if the package is fixed now, this doesn't mean that it's suddenly used.
"It might potentially be used" is not an argument for me. If you think it would be valuable to use Hypothetical usage != actual usage. But if it's actually used - great. |
|
Since Luci is unused, this can go through. If in the future the issue of source provenance in the dependents that current vendor Luci is deemed important enough, it can always be re-added. |
I see. But how exactly do you expect packagers to find the previous work if it's hidden in the git history and closed PRs? The more likely scenario is that they'll think they'll have to start from scratch, lessening the chance that a source build is considered feasible. This might be just another step on |
|
Nix expressions can exist without being in nixpkgs. |
|
It's also common to look for open/closed/dropped PRs or any other forms of prior art when you're about to package something. |
Has been failing to build for 5 months. It doesn't seem to be useful on its own, but only in conjunction with other packages, which are not in Nixpkgs.
From #437082 (comment):
There's an alternative PR to update it to unbreak the build in #437389. I suggest to drop it instead with the option to add it again, when any other package makes use of it.
Note: It also has quite long build times, it took 14 minutes for me to actually hit the test failure. Even if successful, this build is currently a waste of resources, if unused.
Can't request him for review, thus the ping here: @zeuner
Closes #437389
Things done
Add a 👍 reaction to pull requests you find important.