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

[Dave Reisner]

On Tue, Jul 02, 2013 at 10:38:47PM +0200, Alain Kalker wrote:
> 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

You make zero mention of makepkg or any external build tool in that
environment. I'm not sure how you expect anyone to pick up your veil and
dispute your method of compilation. Quite frankly, this is rude of you,
regardless of whether or not makepkg is at fault.

> 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'?

Yeah, I do. They aren't the same thing. I'd be happy to provide a test
case for you where makepkg mangles the pacman build. It even affects the
package in [core] right now. It's something that I absolutely can't
reproduce with a manual build.

> 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!

The PKGBUILD contains the exact same commands as the ones in your log.
It's pretty easy to figure out what correlates to what. If your PKGBUILD
is too complex for you to dissect/debug it, maybe you should reconsider
how you've written your PKGBUILD.

> >
> >>>-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.

And I'm not convinced by your reasoning. Fortunately, the burden of
proof is on you, not me.

I'll let others weigh in, but I have no interest in this, especially if
you're going to ignore the better features of PS4.

d