Arch Linux

Please read this before reporting a bug:
https://wiki.archlinux.org/title/Bug_reporting_guidelines

Do NOT report bugs when a package is just outdated, or it is in the AUR. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!
Tasklist

FS#23765 - [srcpac] Compile and optionally preserve build-time dependencies

Attached to Project: Arch Linux
Opened by Andrej Podzimek (andrej) - Thursday, 14 April 2011, 18:01 GMT
Last edited by Andrea Scarpino (BaSh) - Monday, 17 October 2011, 22:36 GMT
Task Type Feature Request
Category Arch Projects
Status Closed
Assigned To Andrea Scarpino (BaSh)
Architecture All
Severity Medium
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 2
Private No

Details

The summary says it all.

Currently, build-time dependencies are installed using pacman and the user is prompted for their removal after srcpac finishes building the package that required them. With --noconfirm, these dependencies get uninstalled automatically. This may not be suitable in many situations. Some users like to use ArchLinux in a Gentoo-like manner, with srcpac updates. :-) It would be great if build-time dependencies could be compiled rather than downloaded and then preserved for future building. Uninstalling and reinstalling build-time dependencies before and after building every single package that requires them does not seem to be the ideal approach.

It would be nice to have

* an option to prevent build-time dependencies from being uninstalled.
* an option to compile build-time dependencies rather than downloading them.
This task depends upon

Closed by  Andrea Scarpino (BaSh)
Monday, 17 October 2011, 22:36 GMT
Reason for closing:  Implemented
Comment by Andrea Scarpino (BaSh) - Tuesday, 19 April 2011, 13:40 GMT
srcpac >= 0.10.3 doesn't remove makedepends and add an option (-Sm) if you want to remove them.
Comment by Andrej Podzimek (andrej) - Saturday, 08 October 2011, 13:34 GMT
Yes, it doesn't remove MAKEDEPENDS. But it does *not* build them either. The current srcpac (checked out from Git today) simply downloads and installs MAKEDEPENDS with pacman. It would be nice to build them instead. (After all, that's what the -b option is meant to do...)

Alternatively, as already suggested in some of the other requests, there might be multiple alternatives to the -b option, such as:
-b ... build the requested packages from source, download DEPENDS and MAKEDEPENDS with pacman.
-bb ... build the requested packages and DEPENDS from source, download MAKEDEPENDS with pacman.
-bbb ... build *everything* from source, no exceptions.

It is currently not clear which of the dependencies are downloaded, but I definitely see pacman downloading lots of packages during all the srcpac updates. Well, perhaps srcpac somehow prompts the user before downloading/building the dependencies. But since I mostly use the --noconfirm mode, I may not see the prompt asking me whether to build or download... That's why --noconfirm -bbb would be nice. :-)
Comment by Andrea Scarpino (BaSh) - Saturday, 08 October 2011, 13:38 GMT
yes, I'm fine with this solution (-b, -bb, -bbb). Stay tuned! ;)
Comment by Andrea Scarpino (BaSh) - Monday, 10 October 2011, 10:34 GMT
Please test the latest git
Comment by Andrej Podzimek (andrej) - Friday, 14 October 2011, 16:27 GMT
Yeah, the -bbb stuff seems to work. But there might be a bug in the dependency tree handling. Dependencies that are already installed should not be (re)built again, but this probably happens with every updated package. Consequently, updates take an inordinate amount of time and some common dependencies seem to be rebuilt over and over again.
Comment by Andrea Scarpino (BaSh) - Friday, 14 October 2011, 17:27 GMT
Ouch. Thanks for the feedback.
Comment by Andrea Scarpino (BaSh) - Monday, 17 October 2011, 19:12 GMT Comment by Andrej Podzimek (andrej) - Monday, 17 October 2011, 20:46 GMT
Right now I can't build srcpac-git from AUR for some reason...

/usr/bin/msgfmt: error while opening "po/*.po" for reading: No such file or directory
Comment by Andrea Scarpino (BaSh) - Monday, 17 October 2011, 21:08 GMT
That's because there was no translations. Try now.
Comment by Andrej Podzimek (andrej) - Monday, 17 October 2011, 22:28 GMT
Yes, it works now. However, there seems to be a glitch related to package name resolution:

srcpac --noconfirm -Sbbb nss_ldap pam_ldap
Error: Could not find libldap>=2.4.18 under /var/abs/
Error: Could not find libldap>=2.4.22 under /var/abs/

Source Targets: nss_ldap pam_ldap
==> ERROR: requested package nss_ldap is not provided in /var/srcpac/nss_ldap/PKGBUILD
==> ERROR: requested package pam_ldap is not provided in /var/srcpac/pam_ldap/PKGBUILD
Build failed for: nss_ldap pam_ldap

There are two obvious inconsistencies in these error messages:
1) libldap 2.4.26 is available in /var/abs/core/openldap/PKGBUILD, so it should be found.
2) Both nss_ldap and pam_ldap *are* provided by their respective PKGBUILDs, but nss_ldap only has the default package() function (with no suffix) and pam_ldap() doesn't have its own package() implementation at all.
Comment by Andrea Scarpino (BaSh) - Monday, 17 October 2011, 22:36 GMT
Well the problem are the versioned deps, a sed rule should be fine:
https://projects.archlinux.org/srcpac.git/commit/?id=08bddd3a48e416d24c4b2ce844349a852392f1af

I'm closing this bug report as the feature has been implemented, please report any bug in a new bug report. Thanks

Loading...