[aur-general] Is it okay to mark broken packages out-of-date on AUR?
stefan-husmann at t-online.de
Fri Jan 14 14:10:07 EST 2011
Am 14.01.2011 10:45, schrieb Peter Simons:
> Hi guys,
> the AUR user palmfron has recently flagged the package "haskell-haskcore"
> out-of-date, because the PKGBUILD is broken. It cannot be compiled,
> because it depends on other packages that no longer exist:
> Now, there is disagreement among the members of the ArchHaskell team about
> whether it's okay to flag that package out-of-date. Some argue that the
> package is *not* out-of-date, because the published version 0.1.0.4 is the
> latest one available, so the package cannot be updated to a newer version.
> These people argue that flagging a package out-of-date just because it's
> broken is not alright.
> Others say that it's perfectly alright to flag that package out-of-date,
> because it's *broken*, so clearly the PKGBUILD does need updating to be
> Is there some sort of consensus among AUR maintainers how to deal with
> that kind of situation? If an AUR package is current, so to speak, but it
> doesn't compile, then what should be done with it?
> This issue is of some importance for us, because the 'arch-haskell' user
> has published an approximated 500 packages on AUR that are broken, i.e.
> these packages cannot be built because of unsatisfiable dependencies:
> I'd appreciate any advice that you could offer.
> Take care,
IMHO a package that is broken deserves other kind s of love than just an
out-of-date flag. There should be a comment with at least some hints what
may cause the problem.
Out-of-date-flags are, what the name suggests, hints that there is a newer
But some maintainers seem to see that differently. They want a comment
_and_ the out-ofdate-button to be pressed, if the package is broken. Do not
know why. To me this is annoying.
More information about the aur-general