guix-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] gnu: Fix load-extension path in packaging of guile-ncurses.


From: Mark H Weaver
Subject: Re: [PATCH] gnu: Fix load-extension path in packaging of guile-ncurses.
Date: Sat, 24 Dec 2016 10:39:40 -0500
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1 (gnu/linux)

John Darrington <address@hidden> writes:

> We can argue about this till we're blue in the face.
>
> But on a pragmatic level, Mark's question demonstrates perfectly
> that our current system is lacking.

No it doesn't.  Our convention, taken from the GNU coding standards, is
that the rationale for non-obvious code belongs in the code itself.  My
question demonstrates perfectly that you should have done _that_.

For what it's worth, I agree that there are some cases where adding
rationale comments to the code itself doesn't make sense (e.g. when
removing code), but this is clearly not one of those cases.

>      > Having it in the commit message would certainly have avoided me 
>      > having to explain the situation to Mark too.
>      
>      Perhaps. I doubt it. I can't speak for Mark, but most confusion
>      seemed to stem from the commit message's accuracy, not its length.

Yes, exactly.

To be honest, I find it unsettling that after all that has been pointed
out in this thread, you still seem unwilling to admit that you made any
mistake here.

Have you looked at the build log, and specifically the part of the build
log that corresponds to your 'fix-libguile-ncurses-file-name' phase?

Have you noticed how the 'build' and 'install' phases consist mostly of
commands that were already run in your custom phase?

Do you still think that "Install shared object before attempting to
build the package" is an accurate statement?

       Mark



reply via email to

[Prev in Thread] Current Thread [Next in Thread]