yay hangs when attempting to install caret-bin

[cweagans]

Affected Version

yay v6.786

Issue

When attempting to install caret-bin, yay just hangs. I've confirmed that the caret-bin package will build and install manually using makepkg -si.

Steps to reproduce

1. yay caret-bin
2. no cleanBuild, skip editing PKGBUILD
3. wait forever

[Morganamilo]

Looks like this is the cause mikkeloscar/gopkgbuild#24. Basically the file doesn't end in a new line. It's good practice to end in a new line but obviously it should be able to work just fine if it doesn't.

As a work around if you choose to edit the file then just write quit, vim should but a new line at the end for you.

As for gopkgbuild, that issues been open for 13 days with no response. I've actually thought of writing my own version of it, with proper split package support and all that. But that won't be any time soon.

[cweagans]

Doesn't look like I can edit the pkgbuild during the install process either - it just hangs still. I'll see if the caret-bin maintainer will just add a newline to the pkgbuild though. Hopefully that solves it.

[Morganamilo]

Can you attach a log upto the point it hangs?

[cweagans]

Just the console output?

❯ yay caret-bin
1 aur/caret-bin 3.4.6-1 (+6 0.85%) 
    Premium Markdown Editor http://caret.io
==> Packages to install (eg: 1 2 3, 1-3 or ^4)
==> 1
:: Querying AUR...
:: Checking for conflicts...
:: Checking for inner conflicts...
[Aur: 1]  caret-bin-3.4.6-1

  1 caret-bin                                (Build Files Exist)
==> Packages to cleanBuild?
==> [N]one [A]ll [Ab]ort [I]nstalled [No]tInstalled or (1 2 3, 1-3, ^4)
==> n
==> PKGBUILDs to edit?
==> [N]one [A]ll [Ab]ort [I]nstalled [No]tInstalled or (1 2 3, 1-3, ^4)
==> a

If there's an actual log file somewhere, I don't know where it is, but I'm happy to provide it.

[Morganamilo]

Weird that it crashes there. I'll look into it when I'm able. You can edit manually via ~/.cache/yay/caret-bin/PKGBUILD.

Just to confirm it is because of the new line.

[cweagans]

I added a newline, and it's still hanging. Very strange.

[Morganamilo]

Hmm my assumption may be off then. Have you tried it with yay-git.

Other than that I'll have to look into myself when I can.

[cweagans]

I'll give it a go after work :)

[Morganamilo]

I realise I misspoke, It's the .SRCINFO that's missing a new line, Yay doesn't actually read the pkgbuild. I tested it myself and that did fix it for me.

[cweagans]

Oh! Great, I'll try that tonight as well.

[Sasasu]

Fixed.

maybe pacman doesn't require new line before EOF, but any text file should have.

[Morganamilo]

Thanks for fixing it, I wonder if my issue will get a reply any time soon.

[Morganamilo]

@Jguer @mikkeloscar

I got bored and decided to write up my own srcinfo parser.

https://github.com/Morganamilo/go-srcinfo
https://godoc.org/github.com/Morganamilo/go-srcinfo

All the theory is there, it's relatively untested though. I don't plan on moving Yay over to it any time soon just wondering what you think.

[Jguer]

I'll give it a proper look once I have a little hole of time, but I'm glad to see you have time available to be bored 😆

[Morganamilo]

i'm glad to see you have time available to be bored

Hey now, everybody gets bored.

I't only took a couple of hours to write, now I've gone back and done all the tests and finished it up so consider it basically 100% complete.

[Jguer]

Do you think there are advantages to moving over to https://github.com/Morganamilo/go-srcinfo?

Also bored and avoiding work:
https://gist.github.com/Jguer/7ba32039e68dfb67a25f684e119eca3c
Test Run

=== RUN   TestMorganaBiggest
--- PASS: TestMorganaBiggest (0.00s)
=== RUN   TestMikkelBiggest
--- PASS: TestMikkelBiggest (0.00s)
=== RUN   TestMorganaAll
--- PASS: TestMorganaAll (0.01s)
=== RUN   TestMikkelAll
--- PASS: TestMikkelAll (0.03s)

Normal Bench

BenchmarkMorganaBiggest-4           3000            441375 ns/op
BenchmarkMikkelBiggest-4            1000           1290493 ns/op
BenchmarkMorganaAll-4                100          10611026 ns/op
BenchmarkMikkelAll-4                  50          24093379 ns/op

-benchtime=10s -benchmem

BenchmarkMorganaBiggest-4          30000            449516 ns/op          212192 B/op       2079 allocs/op
BenchmarkMikkelBiggest-4           10000           1301798 ns/op          178528 B/op       2445 allocs/op
BenchmarkMorganaAll-4           2000      10550111 ns/op         3650784 B/op      37026 allocs/op
BenchmarkMikkelAll-4                 500          25249174 ns/op         3213821 B/op      43146 allocs/op
PASS

I think I can help on your tests as well, but from the results I see I'm not against changing our SRCINFO parser, specially in terms of ops it's nicer

[Morganamilo]

The advantage to switching would be to avoid thing such as mikkeloscar/gopkgbuild#24. Even though caret-bin fixed the new line there's other packages out there.

gopkgbuild has a disapproval of certain characters. Yes makepkg states a pkgname and other fields should not contain certain characters. But frankly I don't care. It's makepkg's job to lint the pkgbuild. If makepkg successfully builds and generates a srcinfo then we should accept it.

There's also split package support. Now we don't need this much because all of our dependency resolving is done through the RPC. There is one thing I have wanted to do though, show .install files. gopkgbuild stores the install file as a string. But in reality each split package may contain its own .install file. So when using gopkgbuild we would end up listing one .install file while ignoring others.

Also in terms of simplicity I find gopkgbuild's lexer approach way overkill for a simple key value pair file. In fact the only reason I havn't fixed mikkeloscar/gopkgbuild#24 is because I don't wan't to have to deal with the lexer.

In terms of actual lines of code (no comments / tests). gopkgbuild is around 850 lines while go-srcinfo is around 450.

[Jguer]

If it doesn't break any of yay's features, I approve the transition to go-srcinfo for the release after current. ( I always like more performance and less memory consumption).
Still @mikkeloscar's AUR library is some of the most concise and beautiful go code I've seen, I think the original AUR library I wrote for yay was faster but it couldn't beat AUR's concise code simplicity

[Morganamilo]

If it doesn't break any of yay's features

I purposely left out paring the values. gopkgbuild has the Depend and CompleteVersion types while go-srcinfo just uses strings. The idea is to do one thing and do it well. We already have a bunch of Dependency parsing in Yay. We can just use that to replace the one instance where we call .Newer.

I think you focus on speed way to too much, the bottleneck here is probably reading the files, you're never going to notice a speed difference between the two.

When I mentioned lines of code I was referring to simple vs complex.

P.S. you may have missed up mixed up which project is which there ;)

[Jguer]

Yes, since we already do it on yay, I agree following unix philosophy on that one.

I think you focus on speed way to too much, the bottleneck here is probably reading the files, you're never going to notice a speed difference between the two.

I do. It's a disease. And binary size and bloat is an even bigger paranoia I try to restrain myself on.

P.S. you may have missed up mixed up which project is which there ;)

For a moment I thought I was reading the benchmark results wrong. You're completely right and I need my coffee, fixed the mistake where it mattered :)