[pacman-dev] [PATCH] makepkg: Log commands to logfile

[Alain Kalker]

On 07/02/2013 10:17 PM, Dave Reisner wrote:
> On Tue, Jul 02, 2013 at 10:05:00PM +0200, Alain Kalker wrote:
>> On 07/02/2013 09:55 PM, Dave Reisner wrote:
>>> On Tue, Jul 02, 2013 at 09:40:13PM +0200, Alain Kalker wrote:
>>>> For debugging PKGBUILDs, and for reporting build failures upstream,
>>>> it is very important to know the exact commands that are executed
>>>> leading up to a problem.
>>>> By using `set -x` and an appropriate value for PS4, commands are
>>>> logged before they are executed.
>>> If you want to report build failures upstream, then building via makepkg
>>> is already wrong.
>> Not if:
>> - the build failure is caused by an Autoconf bug (see FS#35983 -
>> [libxcb] Build failure: .../install-sh: No such file or directory)
> Your patch does nothing to expose the problem you're reporting here.
>
>> - the package is built as vanilla, as possible, as is supposedly the
>> Arch Way.
> I can guarantee you that any sane upstream will tell you to build as per
> *their* instructions (i.e. not using makepkg) if you try and report a
> build failure to them. Regardless of how these failures were discovered,
> they absolutely require manual verification outside of makepkg.
Then your guarantee doesn't mean squat, sorry.. See 
https://bugs.freedesktop.org/show_bug.cgi?id=66413

PKGBUILD build() and package() functions contain build recipes, do you 
honestly suggest that users should copy/paste

$ export VAR1=val1 VAR2=val2 VAR3=val3 [and a bazillion more of those]
$ ./configure [a bazillion configure options]
$ make [a bazillion make options]

into a terminal just to reproduce a failure exposed by running 'makepkg'?
Perhaps later in the triaging process, if it can be proven that the 
makepkg environment interfered with the build and caused the failure, 
but that would be a Bad Thing(TM) in itself, _then_ executing all these 
command by hand would have merit
>> - the logged commands fully reflect the build process, i.e. no
>> interference from outside environment variables, etc.
> Except that by design, specific environment variables are pulled in by
> makepkg.
See my remark above. Since the log file would contain the commands (with 
$variables expanded), it would be very easy to copy/paste these commands 
and run them in a 'clean' build tree.
That's the whole point!

>
>>> -1 on this.
>> Please don't NAK just because you disagree on one possible use of
>> this feature!
>> As I've stated clearly, the patch has other obvious benefits:
>> debugging PKGBUILDs.
>> Thank you.
>>
> You already have the list of commands to be executed right in front of
> you. You're running code that you yourself wrote into the PKGBUILD and
> nothing more.
With the way current logging works, users have to guess what commands 
were executed when. The log only shows the output, not the command that 
caused it. Especially in more complicated PKGBUILDs, that amounts to a 
lot of guessing.
Yes, you could litter your PKGBUILD with (hopefully matched!) pairs of 
'set -x/set +x' commands to selectively log groups of commands, but what 
if you have a whole slew of packages to rebuild in a chroot? What if one 
of them fails and you find yourself having to search back and forth 
among this list to find the dependency that does something wrong, silently?

I'm not convinced by your downvote, please explain.

Kind regards, Alain
>
>
>