Hello Ciaran! With respect to <[email protected]>, we should certainly take into consideration what you decided to neglect... ;->
On Saturday, 14. February 2009 14:51:39 Ciaran McCreesh wrote: > Which of these options sounds most useful as a default behaviour for > foreground and exclusive builds? [...] > 3) Output to stdout / stderr, also keep build logs in a file, and keep > any e* messages in a different file. Even if a build succeeds, it's good to have a build log available in case the installed package doesn't work as expected. In such a case, a user can look into the build log if something looks fishy. Then there are packages that technically succeed to install but in fact don't do anything. We've had that in gks in the past and in one case, users found out only weeks later and meanwhile wondered why the installation was successful albeit the stuff they expected was missing. Another case are packages that install successfully but behave strangely at runtime, e. g. in case of stupid CFLAGS. Being able to look at a build log, yell at the user and moving forward is useful. (You, Ciaran, above all should know that... ;-) ) Furthermore, there are packages that have build system switches which aren't supported anymore, have been removed, etc. Even for a user being able to see in his build log that things have changed and that some dev didn't notice it (remember: Paludis is going strong in Gentoo... ;->) is useful. Finally, I've seen packages successfully install even though at some point something failed non-fatally and, thus, parts of the application were missing. Without a build log being kept by default, debugging that can become rather tiresome. There are lots of other cases which I've certainly failed to mention here but I hope others will help me out with those. :-) > Which of these options sounds most useful as a default behaviour for > background and parallel actions? [...] > iv) Output to build logs only. Show when we start or complete a task > to stdout. If a task has been running for $to_be_determined seconds, > show a status message saying it's still going. This seems to be the least messy. Tails of build logs don't really add much and this default would still give the most important facts: The things which are currently happening, what already happened and that things are still well currently. All the gory details can be looked up in the logs. Best regards, Wulf
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ paludis-user mailing list [email protected] http://lists.pioto.org/mailman/listinfo/paludis-user
