[aur-general] Is it okay to mark broken packages out-of-date on AUR?
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: http://aur.archlinux.org/packages.php?ID=20383 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 useful. 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: https://github.com/archhaskell/habs/issues#issue/4 I'd appreciate any advice that you could offer. Take care, Peter
On 14/01/11 19:45, Peter Simons wrote:
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?
I'd say that is what the comment section is for. Allan
On Fri, Jan 14, 2011 at 09:56, Allan McRae
On 14/01/11 19:45, Peter Simons wrote:
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?
I'd say that is what the comment section is for.
I was initially set on not getting involved in this discussion, but I think it's worth pointing out that the ArchHaskell team does have an issue tracker (on github) for the "Haskell ABS" tree. So putting a link to an issue in a comment is always an option. /M -- Magnus Therning OpenPGP: 0xAB4DFBA4 email: magnus@therning.org jabber: magnus@therning.org twitter: magthe http://therning.org/magnus
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:
http://aur.archlinux.org/packages.php?ID=20383
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 useful.
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:
https://github.com/archhaskell/habs/issues#issue/4
I'd appreciate any advice that you could offer.
Take care, Peter
Hello, 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 version. 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. Regards Stefan
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:
http://aur.archlinux.org/packages.php?ID=20383
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 useful.
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:
https://github.com/archhaskell/habs/issues#issue/4
I'd appreciate any advice that you could offer.
Take care, Peter
Hello,
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 version.
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.
Regards Stefan That way, they show up in your overview which is handy if you get rid of
On 14.01.2011 20:10, Stefan Husmann wrote: the comment mails for some reason. -- Sven-Hendrik
On 14.01.2011 20:10, Stefan Husmann wrote:
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: http://aur.archlinux.org/packages.php?ID=20383
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 useful.
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: https://github.com/archhaskell/habs/issues#issue/4
I'd appreciate any advice that you could offer.
Take care, Peter
Hello,
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 version.
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.
Regards Stefan
That way, they show up in your overview which is handy if you get rid of the comment mails for some reason.
-- Sven-Hendrik
Hi, maybe an extra flag "broken" like "outofdate" would help. Bye Michael
Hi Sven-Hendrik,
Some maintainers seem to see that differently. They want a comment _and_ the out-of-date button to be pressed, if the package is broken. Do not know why. To me this is annoying.
That way, they show up in your overview which is handy if you get rid of the comment mails for some reason.
yes, exactly. Just consider the 'arch-haskell' user, which owns some 2,000 packages. The "My packages" list for that user is spread out over 80 separate pages! It's impossible for me to log into AUR and locate those packages that need maintenance by checking the comment sections of 2,000 packages. Packages that are marked out-of-date, on the other hand, have an index of their own, so those are way easier to find. Take care, Peter
On 16/01/11 17:35, Peter Simons wrote:
Hi Sven-Hendrik,
Some maintainers seem to see that differently. They want a comment _and_ the out-of-date button to be pressed, if the package is broken. Do not know why. To me this is annoying.
That way, they show up in your overview which is handy if you get rid of the comment mails for some reason.
yes, exactly. Just consider the 'arch-haskell' user, which owns some 2,000 packages. The "My packages" list for that user is spread out over 80 separate pages! It's impossible for me to log into AUR and locate those packages that need maintenance by checking the comment sections of 2,000 packages.
Packages that are marked out-of-date, on the other hand, have an index of their own, so those are way easier to find.
This email airs a bit of the "dirty laundry" of the ArchHaskell project. I hope you don't mind. AUR has a few shortcomings. Not having any link to an issue tracker, but instead dealing with everything through comments, is arguably one of them. Scaling, in the sense of a single user with *MANY* packages, is another. But Peter you have yourself, just a few days ago, removed all but ~80 packages out of the ArchHaskell ABS tree, and declared those removed packages as *unsupported*. That means you've effectively removed the issue of scaling for ArchHaskell yourself. At least for the moment. Dealing with errors in the remaining ~80 packages will be quite possible by just creating an issue in our github issue tracker on those rare occasions (they are rare by definition since we provide a repo of pre-built packages). Given this I think this particular discussion is completely pointless at this point in time. When we start adding many more packages, and we don't ourselves build those packages, then this is problem is likely to re-appear. However, the ArchHaskell project would first need make yet another 180-degree turn on its goals. /M -- Magnus Therning OpenPGP: 0xAB4DFBA4 email: magnus@therning.org jabber: magnus@therning.org twitter: magthe http://therning.org/magnus
participants (6)
-
Allan McRae
-
Magnus Therning
-
Michael Trunner
-
Peter Simons
-
Stefan Husmann
-
Sven-Hendrik Haase