How do I list all make dependencies of a package?

fusion809 · 2016-03-14 16:39:15

Hi,

I have seen this topic, and searched the pactree command's man page, but unfortunately it seems I cannot use pactree to list a package's make dependencies (and only their make dependencies, not their runtime dependencies). I have performed a Google search for 'list make dependencies arch linux' and it returned no usable results. Then I ran a Google search for 'list "make dependencies" arch linux' and it too returned no usable results. The reason I would like to be able to list a package's make dependencies only is that I am building packages for Arch Linux in my Open Build Service Arch_Extra project and if you look here you will see that I am having quite a few issues related to missing make dependencies. So I would like to be able to list, in a nice linear format (similar to the format produced by pactree -l) the make dependencies of the python-sphinx package.

Thanks for your time,
Brenton

Last edited by fusion809 (2016-03-14 16:40:04)

eschwartz · 2016-03-14 17:02:22

makedepends is not relevant to pacman.

You can find the makedepends in the PKGBUILD, which is parsed by makepkg. So you could do something like:

for i in */;  do (cd $i && source PKGBUILD && echo "dependencies for $pkgname:   ${makedepends[@]}"); done

Question: why are you trying to build packages in the main repos, and why doesn't the "Open Build Service" automatically resolve dependencies that are clearly available in the main repos?

Last edited by eschwartz (2016-03-14 17:02:41)

fusion809 · 2016-03-14 17:14:21

The OBS has strict licensing requirements for packages available in its official distro repositories. The [community] repo contains some packages that do not fulfil their licensing requirements. This is the excuse they use for not including the [community] repo, as apparently no one has the time to sift out the problem packages in the [community] repo and just add the OK packages to their copy of the repo. I don't like it anymore than you seem to, rofl, in fact I created a openFATE (openSUSE/OBS site for feature requests) feature request over this here. I also inquired about workarounds for this issue, here at the openSUSE Forums, where I also had a little whine about the situation.

fusion809 · 2016-03-14 17:15:44

Oh and I don't just want the make dependencies just for the package, I also want its make dependencies' make dependencies. So its make dependency tree is probably the better term for what I want. So I think your solution may not quite work. Sorry for not being clear, I should have clarified what I meant.

Last edited by fusion809 (2016-03-14 17:17:00)

alphaniner · 2016-03-14 17:41:39

Instead of a verbose print, you can return the makedepends in a way that can be reused:

 makedeps=( $(source PKGBUILD && printf '%s\n' "${makedepends[@]}") )

But then you have to retrieve the PKGBUILD for all those packages and repeat the process recursively...

eschwartz · 2016-03-14 18:05:57

fusion809 wrote:

Oh and I don't just want the make dependencies just for the package, I also want its make dependencies' make dependencies. So its make dependency tree is probably the better term for what I want. So I think your solution may not quite work. Sorry for not being clear, I should have clarified what I meant.

yaourt and other AUR helpers have logic to recursively build AUR dependencies, and yaourt at least also has the ability to recursively build through the ABS. Perhaps you could see how they do it.

Or just sync all makedepends through the ABS (obviously using something more appropriate than a verbose echo), then sync all makedepends of synced ABS packages, repeat until nothing happens anymore.

...

Again, the makedepends is not a recognized concept by pacman, and it isn't bloating the sync databases.
The only thing that uses makedepends is makepkg, and makepkg assumes you have the community repo enabled and that all make/depends exist. Because that's how repos are supposed to work.

Perhaps you could revive the arch-community OBS repo you mentioned in your OBS forum thread.

Last edited by eschwartz (2016-03-14 18:08:23)

Alad · 2016-03-14 20:06:53

Why are we still sourcing PKGBUILDs by hand when we have mksrcinfo?

Anyway, pacsift could help here:

https://github.com/andrewgregory/pacutils

Get the python-sphinx PKGBUILD via svn or rsync, print its makedepends, and pass to them on to pacsift, e.g

pacsift --sync --exact --satisfies=<foo> --satisfies=<bar>

Get the remainders again via svn or rsync, rinse and repeat (until none remain). You can use tsort to get the order to build them in.

edit: I have scripts for the pacsift and tsort part you could modify:

https://github.com/AladW/aurutils/blob/master/aursift (remove community{,-testing})
https://github.com/AladW/aurutils/blob/master/aurqueue

Last edited by Alad (2016-03-14 20:38:56)

eschwartz · 2016-03-14 21:05:48

Alad wrote:

Why are we still sourcing PKGBUILDs by hand when we have mksrcinfo?

Because it doesn't actually matter whether you source it in a script or by hand, and mksrcinfo by design prints out all the information in yet another needs-to-be-parsed form (the SRCINFO). Whereas using the makedepends variable (contained in a bash script) inside another bash script, is a pretty good justification for sourcing it and keeping it as a bash variable.

So you started off with one problem, and figure the best solution is to exchange it for another problem -- installing an extra package along the way, rather than using makepkg --printsrcinfo directly???

...

SRCINFO was a solution to a very specific problem -- that problem being the unreliability of non-bash parsers for bash scripts, and the insecurity of actually running everyone's arbitrary bash scripts on the AUR host server for the sake of obtaining the package metadata.
That doesn't automatically make it the best solution every problem that comes along.

Alad · 2016-03-14 21:08:01

So you started off with one problem, and figure the best solution is to exchange it for another problem -- installing an extra package along the way, rather than using makepkg --printsrcinfo directly???

Except that makepkg --printsrcinfo is way slower than mksrcinfo.

Either way, that was just one remark of mine, the rest of my post still applies. Easy enough to move things to "source ... printf ..." if you were so inclined (you would only do this with official PKGBUILDs, for obvious reasons). And as far as you're concerned, all I've seen is "do what yaourt does" and "source a PKGBUILD".

Last edited by Alad (2016-03-14 21:19:08)

eschwartz · 2016-03-14 21:26:02

Alad wrote:

So you started off with one problem, and figure the best solution is to exchange it for another problem -- installing an extra package along the way, rather than using makepkg --printsrcinfo directly???
Except that makepkg --printsrcinfo is way slower than mksrcinfo.

Sorry -- my bad.
I was using pkgbuild-introspection-git and didn't realize that no new version was released.
The current git version actually runs makepkg --printsrcinfo rather than duplicating the logic. That has always been the plan, mksrcinfo only really existed because makepkg only made a .SRCINFO if you created a source package.

Either way, that was just one remark of mine, the rest of my post still applies. And as far as you're concerned, all I've seen is "do what yaourt does" and "source a PKGBUILD".

I do consider sourcing the PKGBUILD to be superior to using a srcinfo in this case.
As for pacsift, I guess that is useful in the event of a dependency only being available via a provides -- something I hadn't originally considered.
As for your edit, I took a very quick look at those scripts and couldn't figure out what they are for. Also I don't see any usage info.

Alad · 2016-03-14 22:14:27

The current git version actually runs makepkg --printsrcinfo rather than duplicating the logic.

Huh, thanks for the heads up.

As for your edit, I took a very quick look at those scripts and couldn't figure out what they are for. Also I don't see any usage info.

Sorry about that, issue #1 is improving documentation.

About the original problem, I came up with this script (quick work, not clean or anything):

edit: doesn't work properly

which gives:

archie@thinkpad ~/test_sphinx % ls
docutils  python-jinja  python-pygments  python-six  python-sphinx

N.B: I went with pacinfo, since pacman -Si doesn't seem to display pkgbase (for svn).

Last edited by Alad (2016-03-15 08:54:58)

Arch Linux

#1 2016-03-14 16:39:15

How do I list all make dependencies of a package?

#2 2016-03-14 17:02:22

Re: How do I list all make dependencies of a package?

#3 2016-03-14 17:14:21

Re: How do I list all make dependencies of a package?

#4 2016-03-14 17:15:44

Re: How do I list all make dependencies of a package?

#5 2016-03-14 17:41:39

Re: How do I list all make dependencies of a package?

#6 2016-03-14 18:05:57

Re: How do I list all make dependencies of a package?

#7 2016-03-14 20:06:53

Re: How do I list all make dependencies of a package?

#8 2016-03-14 21:05:48

Re: How do I list all make dependencies of a package?

#9 2016-03-14 21:08:01

Re: How do I list all make dependencies of a package?

#10 2016-03-14 21:26:02

Re: How do I list all make dependencies of a package?

#11 2016-03-14 22:14:27

Re: How do I list all make dependencies of a package?

Board footer