Missing dependencies

[zakhcst]

Description

Dependency not available in arch repos.

Expected Behavior

Build and install.

Current Behavior

Failure to build both dev and non_dev.

[aurman|master]$ makepkg -si -p PKGBUILD_NON_DEVEL ==> Making package: aurman 2.10-1 (Tue 12 Jun 2018 14:38:31 BST) ==> Checking runtime dependencies... ==> Installing missing dependencies... error: target not found: expac-git ==> ERROR: 'pacman' failed to install missing dependencies. [12/06/18 14:38:31 ~/builds/aurman] [aurman|master]$ pacman -Ss expac-git [12/06/18 14:39:01 ~/builds/aurman] [aurman|master]$

Version of aurman you are using

• latest git clone http....

[Morganamilo]

AUR packages can depend on other AUR packages: https://aur.archlinux.org/packages/expac-git

[polygamma]

non development aurman does not depend on expac-git btw. https://aur.archlinux.org/packages/aurman

[zakhcst]

This is not how it behaves as shown above.

[polygamma]

you are not supposed to clone this repo and use the pkgbuild found here. read the arch wiki entry regarding the aur before opening wrong bug reports, thanks.

[zakhcst]

Thanks

[polygamma]

Now aurman depends also on expac-git, not expac. That's not what I want, but currently it has to be that way.

[kbumsik]

Hi @polygamma , I noticed the dependancy change in AUR package today (expac -> expac-git), but I am a bit hesitated to switch to expac-git just for aurman. Do you have a plan to switch back to expac?

[polygamma]

Yes, when a needed commit is in expac

[polygamma]

relevant: https://github.com/falconindy/expac/pull/35#issuecomment-396977370

[regeya]

I mean, it's cute and all that you closed the bug and marked it as invalid, but your package updates itself from the aur, and you have 2.13.1-1 marked as the release version, which depends on expac-git>=8.1.g5ae006f which the maintainer has set to be version 3.9.g7a73405-1 for some reason.

https://aur.archlinux.org/packages/aurman

https://aur.archlinux.org/packages/expac-git/

If you're going to simply close bugs now because you don't want to deal with it, please let us all know so we can find another aur helper.

[polygamma]

@regeya you should get yourself familiar with how -git packages work, if you build and install the current expac-git version, it indeed is 8.1.g5ae006f-1, see:

[jonny@jonny-arch-pc ~]$ pacman -Qi expac-git
Name            : expac-git
Version         : 8.1.g5ae006f-1
Description     : pacman database extraction utility
Architecture    : x86_64
URL             : http://github.com/falconindy/expac
Licenses        : MIT
Groups          : None
Provides        : expac
Depends On      : pacman
Optional Deps   : None
Required By     : aurman-git
Optional For    : None
Conflicts With  : expac
Replaces        : None
Installed Size  : 50.00 KiB
Packager        : Unknown Packager
Build Date      : Wed 13 Jun 2018 10:20:06 PM CEST
Install Date    : Wed 13 Jun 2018 10:20:10 PM CEST
Install Reason  : Explicitly installed
Install Script  : No
Validated By    : None

[polygamma]

Hence it has nothing to do with me unwilling to fix bugs, and to be honest: it's an impertinence to insinuate that I don't care about bugs. Look at recent issues, which are marked with the label bug and see how I dealt with them. Maybe you really should use another AUR helper, because people like you are the reason for issues like https://github.com/polygamma/aurman/issues/140

[polygamma]

I have banned you from this repository because I do not care what else you have to say.

[polygamma]

@jaredallard, what kind of instructions are those? using yaourt to install expac-git, but not aurman? wtf?

edit: the instructions have been removed by me.

[jaredallard]

@polygamma These instructions assume that someone does not have aurman currently, a lot of distros and people already have yaourt installed. I could also have supplied a git; makepkg instruction set instead

EDIT (for clarification): This scenario is a bit off from the actual issue, but occurs when someone is attempting to install aurman

[polygamma]

you do not get what i said. why would you install expac-git, but not aurman with yaourt? your instructions simply do not make sense. if one thinks that is sensible, that one should not use an aur helper at all

[jaredallard]

@polygamma Gotcha, because this issue occurs w/ yaourt -S aurman as well. There's no need to be condescending. I am simply attempting to provide context and instructions to anyone else who comes across this issue.

[polygamma]

yaourt does not support vcs packages? and yaourt also does not allow the installation of aurman after expac-git has been installed?

[jaredallard]

It does support VCS packages, but it will fail to find that version of expac-git because the maintainers set version is not in that range (not the actual eval'd version)

After it is installed, it could work, I didn't test that. But then you'd just eliminate the need to makepkg for aurman

[polygamma]

I installed yaourt to test this and indeed executing yaourt -S expac-git and after that yaourt -S aurman allows the installation of aurman, hence your install expac-git with yaourt and install aurman via makepkg does not make any sense, as written in: https://github.com/polygamma/aurman/issues/153#issuecomment-399712886

Besides that: Not sure why you even want to provide these steps, because the aurman README states that users unable to install aurman should not use aurman, and thus you are doing exactly what I do not want: Help users, who should not use aurman, to install aurman. And doing that in the GitHub repository which states those points - nice.

[polygamma]

Obviously it does not support VCS packages, if it is unable to handle that case in one transaction, but thanks for proving my point then.

[jaredallard]

@polygamma See edit, I expanded on that installing them out of order could work, expac-git -> aurman and it just wasn't a use case I tested. I have edited my initial comment to reflect that for less typing.

I'm not telling you how to maintain/develop your software, as a maintainer of many projects myself I understand that. I don't, however, see the harm in expanding upon an issue. This, again, is open source software. There should be no (gate?) to utilizing it. I merely provided input on how to work around this.

[polygamma]

I see the harm in expanding this because of the bullshit I have to deal with afterwards. Look at the recent issues in this repository marked as invalid or the shitty comments here. You do not believe how many have been removed from that page already. Users not understanding the basics of pacman, makepkg and the AUR in general, blindly following instructions found on the internet to install aurman and since they would not have been able to install aurman on their own, they have not the slightest idea of what they are even doing, which leads to opening shitty issues in this repo, sending shitty emails, posting shitty comments on the AUR package page, posting shit on reddit and in general just annoying the fuck out of me. It's getting harder and harder for me to even find out what users are doing because of instructions suggesting to change the PKGBUILD, to remove the expac-git dependency and replace it with expac, which leads to aurman malfunctioning in very subtle ways etc. Look at the detailed README and the Issue Template. Instructions like yours only make my "developer life" harder by allowing incompetent users to use aurman. And doing that in this repository, while I have clarified in the README, that users who are not able to install aurman on their own, should not use aurman, really upsets me.

[polygamma]

I have removed the steps you posted. If you feel entitled to post them again, you will be banned from this repository. Feel free to post them anywhere on the internet, if you want to "help users", but do not do it here.

[eli-schwartz]

Sigh.

To quote myself on the aurman comments page on the AUR:

The goal of bootstrapping packages which require versioned dependencies, of VCS packages for which the version will only be calculated when actually running makepkg to build the package, is fundamentally incompatible with upfront dependency resolution. In order to install expac-git and aurman at the correct versions, it is necessary to first install expac-git on its own, then install aurman.

This is not a problem to be solved by AUR helpers. AUR helpers can do a lot, but they cannot completely obviate the need for human interaction.

You're a Turing-complete user -- act like it.

I'm not sure how much clearer I could possibly get. aurman is perfectly capable to be installed, expac-git notwithstanding, to anyone who has a basic understanding of VCS packages and follows my fairly bulletproof advice. This is not rocket science. Users who cannot grasp this are beyond hope -- there are so many ways for them to get in trouble while using the AUR, their issues with aurman hardly register.

I don't see the need to offer advice specific to some AUR helper. I definitely don't see the need to offer confusing, contradictory advice specific to one AUR helper, on the grounds that users of some other distro will have that helper preinstalled.

[jaredallard]

Good god, it's great to see that elitism is still alive and well in the arch community. My interest in this aur helper has diminished so I doubt I'll return to this project again, since there is clearly no concern for usability.

Hopefully this projects scope changes and decides to not remain elitist and purist and instead decides to, I don't know, benefit everyone. The easiest to use tools are the most popular (e.g Docker). That's my two cents.

[eli-schwartz]

Then you've been deeply misinformed, and someone did you a massive disservice when they recommended Arch Linux. Arch Linux has always been and will always be deeply opposed to being a popularity contest.

To quote the venerable wiki definition of Arch Linux:

https://wiki.archlinux.org/index.php/Arch_Linux#User_centrality

Whereas many GNU/Linux distributions attempt to be more user-friendly, Arch Linux has always been, and shall always remain user-centric. The distribution is intended to fill the needs of those contributing to it, rather than trying to appeal to as many users as possible. It is targeted at the proficient GNU/Linux user, or anyone with a do-it-yourself attitude who is willing to read the documentation, and solve their own problems.

The official position of Arch Linux, as embodied by the Developers, Trusted Users (e.g. me), Bug Wranglers (e.g. me), forum staff, and wiki admins, and unofficial position of the many longstanding regular community members, is that we don't feel hurt by what you just said. We do feel sorry, however, for people who mistakenly thought Arch Linux was targeting them as a userbase, and as a result of this unfortunate misunderstanding, ended up involved in unhappy arguments and also suspecting us of an elitist attitude we do not, in fact, possess.

Like most organized bodies, Arch Linux has a guiding ethos. Within the bounds of this ethos, we are quite happy to engage with people. (I will also note that many Linux newbies have been cheerfully welcomed by our community, and credit us with greatly enhancing their knowledge and providing an incredibly valuable learning experience.) Outside of the bounds of this ethos, and specifically when outsiders come in and extensively violate this ethos (sometimes through deliberate malice, sometimes though uninformed ignorance of the rules of the community)... well, outside of the bounds of this ethos, we're not very happy to engage at all. But I guess this is understandable, since a set of community rules and guidelines which are not enforced, might as well not exist.

To be clear, we're a special-interest group, and what you want lies outside of this. Not only that, you're explicitly asking us to deny our whole foundational purpose for existing, and adopt a wholly different purpose. Note that the purpose you are asking after, already has many excellent and well-respected groups which already perform an admirable job. This is why, as a special-interest group, we do not accept or undertake missions which lie outside said special interest.

[jaredallard]

There is a difference between user-centric and elitism. User centric does not mean lack thereof clear, and concise documentation that establishes how to utilize and/or install software, I quote:

do-it-yourself attitude who is willing to read the documentation, and solve their own problems.

Does this project contain any actual usable documentation in a tangible form around installation? No, instead it assumes you know how to do something without linking or describing what it is. Therefore it fails that aspect already. 100% of your invalid issues would be solved by a simple quickstart document linked in the readme in bold text at the top. Sure, you'll still get a few issues around invalid usage, but that is what happens with Open Source Software.

I am well aware of what a special-interest group is, as a SRE I interact with many around Kubernetes development. A "technical SIG" is, by definition, not established to be a limiting group but rather an established group that has achieved a high level of expertise in one field. Wrapping around makepkg doesn't make you fit that description nor does the implication of being part of one govern that you must act as if you are higher than everyone.

All of this just further justifies, and shows, that this projects contributors clearly are just annoyed by the intake of new users since this was listed in the wiki. Instead of deciding to write good docs around installation, clear differences between pacman and aurman, you have instead of opt'd to adding invalid to any badly written issues, delete comments that attempt to be actual docs on how to install aurman and write a notice that aurman is not for people who don't know how to debug issues with this software in the README.

Edit: Oh, and continue to insert the fact you are on the Arch Linux team a couple more times. It might make you have even more humility.

[eli-schwartz]

The makepkg documentation can be found here: https://wiki.archlinux.org/index.php/Makepkg

I see no reason for aurman to duplicate this information in a manner that is more likely than not simply going to get old and stale.

The solution to at least 50% of invalid issues across AUR helpers in general, is acknowledging that in Arch Linux, reading that wiki page and the linked AUR wiki page is a hard requirement for using the AUR (and expecting any form of community support whatsoever). We do not write extensive documentation that was an immense labor of love, just to have users refuse to read it and then ask for help which boils down to "quote the wiki at them".

The rest of the most recent invalid issues in this repo, are people complaining that an AUR dependency is explicitly asking for the git version even though that behavior is correct (and advising to incorrectly use the stable release), or complaining that an AUR helper doesn't implement an unrelated feature because yaourt does, several cases where actual aurman-specific issues were already described in the README, complaints about bugs in dependencies from the [extra] repository, complaints due to using broken and outdated versions of aurman provided by non-Arch distros...

I am well aware of what a special-interest group is, as a SRE I interact with many around Kubernetes development. A "technical SIG" is, by definition, not established to be a limiting group but rather an established group that has achieved a high level of expertise in one field. Wrapping around makepkg doesn't make you fit that description nor does the implication of being part of one govern that you must act as if you are higher than everyone.

Does Kubernetes not have any internal governing standards whatsoever for their internal fora, bugtrackers, discussion groups, conferences, etc.? Do they recommend and encourage the use of their software to people who don't know what containers even are? Do they encourage the use of explicitly unsupported tools, noting that Arch Linux explicitly unsupports AUR helpers?

If the answer to any of these questions is "no", then I guess Kubernetes is also an elitist, limiting group which hates on outsiders.

you have instead of opt'd to adding invalid to any badly written issues

But they're legitimately invalid...

delete comments that attempt to be actual docs on how to install aurman

Attempt, badly fail, and run a serious risk of endangering users in the process. That's certainly been my experience with the comments I personally deleted from the AUR page! :)

The canonical documentation for installing packages is, once again, https://wiki.archlinux.org/index.php/Makepkg and it is longstanding Arch policy that any and all other documentation is unsupported. If one cannot deduce how to install packages after reading that page, then we consider it dangerous to use AUR helpers (none of which will ever work 100% of the time, not even this one) and explicitly refuse to support doing so anyway -- and I'm delighted to see that aurman respects Arch policy by referring them to this documentation rather than encouraging helplessness and potentially serious breakage via recursively recursive use of aur helpers to circumvent knowledge.

Edit: Oh, and continue to insert the fact you are on the Arch Linux team a couple more times. It might make you have even more humility.

Eh. I don't think representing the official position of Arch Linux in regard to the type of users we target, is a job that calls for much humility.

[eli-schwartz]

If you have deep, fundamental issues with the entire Arch Linux distribution and its entire 16-year history, culture, and mindset, please find a more appropriate venue of discussion and do not pick this one software project for obeying the rules of the community. Thanks.

[jaredallard]

Again, this project DOES NOT link in ANY way to documentation around makepkg. An easy solution is to, again, write a quick getting started doc that includes links to helpful wiki pages and a short sum up of contributing practices, issue reporting guidelines, and etc.

If someone's issue is off topic, needs more info, or whatever you can easily explain it in the comments or ignore it. Instead of, my personal favorite regarding https://github.com/polygamma/aurman/issues/178

I... I... I... really want to cry. And I wanna scream.

You could easily close that with a link to x doc with instructions on setting up aurman and common issues people run into.

Let's run through a perfect example of how this project should be run, by examining pacman(8) :)

If we look at the homepage of pacman we're taken to an introduction page. Documented here immediately is what pacman is, what it does, and etc. At the end of the releases we can find this helpful note:

Source code for all releases is available at https://sources.archlinux.org/other/pacman/. To install, download the newest available source tarball, unpack it in a directory, and run the three magic commands:

$ ./configure $ make # make install

Well, that's too easy. Nobody needs to know how to install pacman, clearly they should already know that if there is a Makefile they just run a ./configure script if it's there and then find the make targets and move from there.

Under the Development section is a command on how to get the latest source code for development:

Development of pacman is currently done in Git. The central repository is hosted by Arch Linux, although some of the developers have their own trees (ask on the above mailing lists if you are interested in finding the locations of these trees). The current development tree can be fetched with the following command: git clone git://projects.archlinux.org/pacman.git pacman

Well, that's clearly pointless because any good developer would clearly already know how to invoke git and clone a repo. That's pointless, might as well as just include the git URL!

Obviously, since pacman is an official Arch Linux project and has everything I've just mentioned this project should have, then aurman is completely able to provide that same level of documentation since clearly Arch Linux allows it.

RE my "anger?" around Arch. This is obviously not around the Arch Linux community, but rather this project, do not continue to associate this project as being representative of the entire culture and mindset of the distro. I already pointed out the flaws in this project regarding following those (above and in my past comment)

[phillid]

Again, this project DOES NOT link in ANY way to documentation around makepkg. An easy solution is to, again, write a quick getting started doc that includes links to helpful wiki pages and a short sum up of contributing practices, issue reporting guidelines, and etc.

It is the user's job to be familiar with pacman and its build processes. Spoon-feeding is often not sustainable. There is already a fair amount of good information on the beautiful ArchLinux wiki on AUR helpers.

Let's run through a perfect example of how this project should be run, by examining pacman(8) :)

You appear to be able to source manual information yourself. Why do you ask for spoon feeding?

[jaredallard]

Spoon-feeding is often not sustainable

Citation needed. Irregardless of the fact it's not spoon feeding to have basic invocation information as well as installation documented. makepkg knowledge is quite trivial when it comes to a good AUR helper, as you shouldn't ever really need to know how it works to install a package.

I myself do not need help installing aurman, I have already done so. I'm, again, merely trying to help others install it who haven't worked with as much components surrounding aurman as I have.

Not quite sure why you three seem to need to feel like it's some sort of "vetting" process to install this. Open Source Software is available to the public, and now that it's linked in the wiki you're going to continue encountering new people. If you continue to reject them then you'll only end up wasting your time as well as theirs. Again, easily solved by putting a small amount of effort into the readme.

It won't kill you. It won't make you less "cool".

[phillid]

Irregardless of the fact it's not spoon feeding to have basic invocation information as well as installation documented

This "basic invocation information" and installation form basic information that can be determined by anyone capable of compiling and installing any other package from the AUR. For a user prepared to run Arch, it is spoon-feeding.

makepkg knowledge is quite trivial when it comes to a good AUR helper, as you shouldn't ever really need to know how it works to install a package.

If this were the case, then there is no need to link to makepkg documentation. The problem with arguing that AUR helpers should be completely opaque abstraction layers is that there is a bootstrapping problem. Not only for installing a helper itself, but for when an AUR helper breaks or fails to react to a change on the AUR (RPC changes, for example), or for when all or part of their system breaks for one reason or another, resulting in a knock-on breakage to the AUR helper.

Besides, knowing what happens to install a package is vital to understanding the AUR and the dangers that come with it. This issue is evidence of this. The AUR is not a transparent repository from which to install software. It is a cesspit of mostly low-quality PKGBUILDs submitted by complete strangers to the Arch community on the whole.

I myself do not need help installing aurman, I have already done so. I'm, again, merely trying to help others install it who haven't worked with as much components surrounding aurman as I have.

"Working with components" here seems to relate to everyday management of an Arch system. I don't see any elite skillsets beyond what an Arch user mature enough to be running an AUR helper should have here.

Not quite sure why you three seem to need to feel like it's some sort of "vetting" process to install this.

There is no vetting process here above and beyond the normal "turing-complete user" test as referenced by Eli. From the time I have spent in various support channels, I can gauge that what does need to be ensured is for users of AUR helpers to genuinely understand the officially-supported methods of doing things, and to be able to see the dangers of automating the installation of software from the AUR.

Open Source Software is available to the public, and now that it's linked in the wiki you're going to continue encountering new people.

The wiki you mention is published "open source" under the GNU FDL, but people fail to read it at all. Why would documentation here be any different?

Besides, installation is well-defined and well-documented in the PKGBUILD.

If you continue to reject them then you'll only end up wasting your time as well as theirs.

If people fail to engage their brains, they are wasting more of their own time than they are that of anyone else.

Again, easily solved by putting a small amount of effort into the readme.

Easily solved by users knowing how to drive manual/stick in their Linux distribution that has always demanded just that. Duplicating information that is groomed and maintained up-to-date by the community, and that is as accessible and editable to the community as the wiki is folly. Information duplicated elsewhere will only become crusty and stale, requiring maintenance in an effort to create a manual mirror of part of the wiki.

[polygamma]

@jaredallard - it seems like you still do not quite get the point. If my goal would be to make aurman available for as many people as possible, I should include such instructions in the README, yes. You are 100% right with that. But that is not my goal. It also was never my goal. You should know, that I started developing aurman for myself and myself only since you downvoted https://github.com/polygamma/aurman/issues/140#issue-329948852 and thus read that post. Why the downvote btw?

I am still developing aurman primarily for me, but "allow" other people to use aurman, report bugs and request features. And it really is that, I am allowing other people those things, it is my project and my project only. Hence I want the developing of aurman to affect my "developer life" in a negative way as little as possible. And that includes not trying to make aurman available for everybody, because most of the users absolutely suck. Especially those, needing step by step instructions to get started. And those users start annoying me, but only because they are not competent enough to read the Arch Wiki and/or use google. If you do not grasp that, you are one of them.