check-meta: fix 'hasNoMaintainers'

broken in 650eb613e64c49b538b0edece0742ae658971d1f

Previously, if any of `meta.teams` or `meta.maintainers`
was undefined, `hasNoMaintainers` would return false,
suggesting e.g. bash had a maintainer - it does not.

The old logic before meta.teams was:
```nix
  hasNoMaintainers = attrs: attrs ? meta.maintainers && (length attrs.meta.maintainers) == 0;
```
This meant a package that did not define `meta.maintainers` would
appear maintained by this check, while a package with `meta.maintainers = []` would be listed as unmaintained.

This might have been a bug.
If it was not, that logic could be restored by prepending an extra check to the condition:
```nix
  (attrs ? meta.maintainers || attrs ? meta.teams) && (attrs.meta.maintainers or [] == []) && (attrs.meta.teams or [] == [])
```

I believe this makes little sense though. if no maintainer is listed, a package should be considered unmaintained.
If really desired, this can still be bypassed by setting `meta.maintainers = null;` or something.

0 files changed, 0 insertions, 0 deletions