Yay: Yay doesn't install dependecies added to PKGBUILD during installation.

Created on 18 Jul 2018  路  35Comments  路  Source: Jguer/yay

Affected Version

yay v8.992

Issue

Doesn't check for dependencies after editing PKGBUILD

Steps to reproduce

  1. yay -S a package from AUR which has a dependency that isn't listed in it's PKGBUILD
  2. add missing dependecy to PKGBUILD when prompted to (--editmenu has been enabled)
  3. Checking buildtime dependencies...
  4. ERROR: Could not resolve all dependencies

Expected behaviour

checks for dependencies after editing PKGBUILD recursively until satisfied.

The package I encountered this with is appmenu-qt5-git
which depends on qt5-x11extras

All 35 comments

We use the RPC to resolve dependencies ahead of time. Re-resolving the dependencies is not a thing I plan to add.

If there is a problem with the dependencies, as well as installing the dependency yourself I recommend you report the problem upstream.

Maybe you should add it to the FAQ or something, since it's only the 400th issue with this question. (Not that yaourt users who expect this behavior ever look at READMEs... but I digress.)

I guess that's what FAQs are for. Funnily enough only now this question is being asked over and over.

It should be obvious. Ever since yay got a green row on the wiki table, the project has become a new beacon of light (darkness?) for help vampires across the realm. :smile:

which implies those people are not going to open issues in the aurman repo, hopefully...

I would have thought most people would have settled on an AUR helper by now, Moving yay up shouldn't see any immediate boost right?

I have the impression that people really like to switch AUR helpers, because there's always that little thing which bugs the users, hence they try something new

Addition: I also read, that there are users, using multiple AUR helpers at the same time. E.g. aurman for inspecting the PKGBUILDs, .install files etc. and yay for installing the packages.

That sounds really weird. I don't think anyone would go that far to use half of each helper lol.

On another topic I made a nice little aur fetch type tool in go. ability to show the files and diffs through a file manager like vifm and all. Tempted to stick it into yay at some point.

On another topic I made a nice little aur fetch type tool in go. ability to show the files and diffs through a file manager like vifm and all. Tempted to stick it into yay at some point.

Cool :+1: Honestly I think it'd be great if all the AUR helpers used some common interface... though I'm not sure on using Go, if only because I suspect the rest of us have a good working knowledge of C/C++, but perhaps less of Go!

Maybe one should really start to provide more general tools, instead of focusing on providing feature complete AUR helpers. Looking at aurman and yay, I think both of them are great AUR helpers as of now, and they are not that different, when looking at the features. I am sometimes thinking that instead of having written aurman from scratch at the beginning of 2018, I should have gotten engaged in the development of yay.

Maybe one should really start to provide more general tools, instead of focusing on providing feature complete AUR helpers.

Yes, well, that's what I've been doing since 2016, but it never caught on. I guess most people are allergic to command languages. :disappointed:

I guess it's because you are using bash, to be honest. I never even considered forking pacaur because it was written in bash, although I used pacaur before starting the aurman development.

Edit: https://github.com/rmarquis/pacaur/blob/master/pacaur#L959 nightmares are made out of this ;D

I guess most people are allergic to scripting languages.

Yes, yes I am.

I think it'd be great if all the AUR helpers used some common interface...

Honestly I would love to see some AUR tools in the official repos. I get the no AUR helpers logic. But a common search/info/fetch tool would be nice to have. Probably never going to happen though. Unless maybe cower gets a day 2 /s.

The question I asked back then was, with makepkg and PKGBUILDs written in bash, if there was an advantage in using a different, more powerful language. In the end I wasn't convinced, since the AUR is broken monstrosity whatever you do.

Nor was there, perhaps ironically, any performance to be gained. Mainly because I didn't use bash like a poor Python knock-off as people often enjoy doing, but emphasized on pipelines and proper command-line tools.

But a common search/info/fetch tool would be nice to have. Probably never going to happen though. Unless maybe cower gets a day 2 /s.

You don't need AUR tools per se, just a common library that everyone uses. Then all the existing helpers would become thin wrappers over this library. I'd probably emphasize on dependency solving, interacting with the RPC and version comparison. Using git is not so complicated that it needs a separate abstraction imo.

So if there were some C library anyone can use (except end-users :rofl:) with these common but more complex functions, I don't see what would prevent it from being included in community. Notwithstanding some bureaucratic effort and getting such a project off the ground to begin with...

My problem with bash is that every feels like a huge hack. And the quoting oh god the quoting. And my biggest complaint: I don't know it that well. Performance wise I know how efficient pipelining can be.

Also with a libary. Go makes multi threading so easy and we take advantage of it a lot. Which is why Yay tends to be the fastest. ( And we don't call the date command ;) ).

I can imagine threading in c to be a nightmare, not that I've ever tried it.

Well, bash is basically the living embodiment of the UNIX principles: you have a whole range of tools, and combine them in clever ways through stdin/stdout and the file system. So it's a "hack", but in a positive sense really.

Some parts are of course exceedingly annoying, such as being super lax and generally not having a compiler to tell you on easily preventable errors that now manifest during runtime... :slightly_frowning_face:

And we don't call the date command ;)

neither does aurman

I don't have much experience with multithreading (apart from reading the parallel man page), but some threaded APIs look terrible, like curl: https://curl.haxx.se/libcurl/c/threadsafe.html

C just seems the safest bet since you can use it from any language and is ABI stable and all that. Mind you, I agree that it's not exactly the most pleasant experience. If we had a libaur in C, I wouldn't be the one volounteering anyway.

Anyway if you want to make those library/general tool efforts public at some point, feel free to ping me.

It's literally just a fetcher right now. Not even dependency resolving. If I end up with anything substantial I will.

Note that I've thought on porting most parts of aurutils to C++ for a while. I guess it could serve as a baseline if we decide to pull this libaur thing through.

But why c++ when you can just do it in c?

Because

it's not exactly the most pleasant experience.

cf. https://github.com/falconindy/auracle#problem

I guess you could prototype it in some higher level language like Go or C++ and see on how much effort it takes to port it to C

Why not write it in go but only using embedded c code? Oh god even saying that scares me.

What does that entail, is it similar to using assembly in C? (but C in Go?) Also, how is it different from using "cgo"?

Well you have to stick it as a comment next to the c import (goodbye syntax highlighting). Why? Hell knows. Some things in go are just magic.

Take this file for example https://github.com/Jguer/go-alpm/blob/3dfdf3de97386ab6f5d1fb744ec8d9a549021405/package.go. It took me hours to figure out a bug because I was brand new to go and I thought It was just a comment documenting the internals of alpm.

I'm still kind of upset over it, And as far as I know, importing c in go is what "cgo" is.

Thanks, I can see how this is annoying. Anyway I'm open to new things, though it would be nice if most of the major helper authors agree on what language to write libaur in (cc. @polygamma @kitsunyan)

Before cc'ing in everyone you might wanna create a dedicated issue. I don't really wanna see emails titled "Yay doesn't install dependecies added to PKGBUILD during installation." constantly.

Sorry about that, I guess it's a habit left over from the 250 comment discussion in pikaur#301.

That's exactly what I was trying not to cause a repeat of. But feel free to open a dedicated issue here, in aurutils or a new repo, whatever you like.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

parkerlreed picture parkerlreed  路  3Comments

GhostKraft picture GhostKraft  路  4Comments

AdrienLemaire picture AdrienLemaire  路  3Comments

bazeeel picture bazeeel  路  4Comments

tapir picture tapir  路  3Comments