Arch Linux

I think this is covered by comments and mailing the maintainer. If it's broken, emailing the maintainer should elicit a fix. If the person isn't maintaining it, mail aur-general and as for it to be orphaned so you can adopt and update it.

I think that having an easy visualization of broken packages would be nice and easy. (like marking the package red in the search results for outdated packages.)

That has the assumption that packages will be left broken for extended periods of time, which I don't think is a case we should really code for. If it's an orphan and broken, adopt and fix it; if it's maintained, email the maintainer with fixes.

I think it would be nice to have.
Imagine if you had a list of bugs filed against a particular package on the web interface for official packages.
It's a good thing that comments are tied to the package in the AUR, but unfortunately there's no proper bug tracking system.
Something like this would kind of meet the needs mid-way, because we don't really know what comments are bugs and what are just forum-like discussion.

The perfect solution would be proper comment/bug tracking system in the AUR. Hehehe.

It would also be nice to be able to filter packages based on this flag so AUR helpers could give users the option to exclude searching for packages that are broken.

A similar take on this concept I proposed on the aur-dev ML that had some traction: http://mailman.archlinux.org/pipermail/aur-dev/2011-June/001698.html

"That has the assumption that packages will be left broken for extended periods of time, which I don't think is a case we should really code for."

This is certainly no more true or false than a similar assumption about the out-of-date flag? I think it would definitely be worthwhile to be able to distinguish between a package being out-of-date or a package being broken.

Yeah, a lot of maintainers start complaining when I just mark their packages as "out-of-date" when they're actually "broken" (e.g. the source URL has moved or it requires some additional dependency, etc.).

But that's the only flag I got.

I think the flag would be useful to have, because it allows using the information programmatically. An example way to use the information could be automatically orphaning all packages that have been marked broken for more than a certain time (e.g., a month) and removing packages that are marked broken for some other, longer time period (e.g., two/three months). A comment lets a human reading the comment know that the package is broken, but it doesn't let a computer know anything.

Sometimes users need to flag packages outdated because they are broken but not updated, I thing this could help maintainers to know when a package is broken, like if one flag a package broken Need to upload a message saying why (like in official for outdated).
I see sometimes the situation that the maintainer refuse to fix a broken AUR package and f¿prefer wait for upstream, so whit the flag users can know when a package is broken but NOT outdated so they will not spam the outdated buton like now and intead they will know that X package is wroken but not outdated and they know that they will need to dirty they hand when they want to install them.

Now that the package request feature has been implemented: Is this still needed?

Package request are for "merge", "delete" and "orfanity" but none for "broken" so a option to "broken" and instead of send the mail to the mailisting, send it to the maintainer registrated e-mail.

I thing this is the best way....

falconindy's thoughts on the matter back when the Requests were first implemented: https://lists.archlinux.org/pipermail/aur-general/2014-July/029079.html

> Now that the package request feature has been implemented: Is this still needed?

Sometimes I see (and I admit to do that myself too) broken packages being marked as out-of-date. Your question could be then: does 'out-of-dateness' fulfill the hole of 'broken' too?
When people don't mark a package as out-of-date, usually a comment is made; but a comment is easily non-perceived by a user who is just download a PKGBUILD (while a bold red text yields quite the contrary)