FS#25628 - [srcpac] Add support for building packges from Git
Attached to Project:
Arch Linux
Opened by Andrej Podzimek (andrej) - Wednesday, 17 August 2011, 20:26 GMT
Last edited by Doug Newgard (Scimmia) - Monday, 15 May 2017, 17:15 GMT
Opened by Andrej Podzimek (andrej) - Wednesday, 17 August 2011, 20:26 GMT
Last edited by Doug Newgard (Scimmia) - Monday, 15 May 2017, 17:15 GMT
|
Details
Description:
The attached patch adds experimental (shot-in-the-dark) support for building packages from Git instead of ABS. Changes: * Added a configuration file /etc/srcpac.conf with some important variables. * Added initial support for building packages from Git. * The Git repository is first cloned if the appropriate directory is not found. * If the Git repository directory exists, the tree is first reverted to its initial state (local changes purged) and then updated (pulled) from the remote repository. * Added the -z or --git option to build from Git instead of ABS. Without this option, srcpac should behave the same way as the original version. * Fixed a bug when no packages were supplied to pacman and installed after building an entire compound package and selecting the default ("all"/empty) option. * Removed --asroot completely. It does not seem to serve any reasonable purpose. Known issues: * The code branch corresponding to $pkg != $pkgbase in build_packages() never runs. Consequently, *all* packages from compound PKGBUILDs are installed by pacman instead of the required ones only. *This is a bug inherited from the original srcpac. It is caused by calling the build_packages() function with the resolved 'candidates' (package directories) instead of the actual package names required by the command line arguments. *This should be sorted out properly by creating a mapping of the candidate directories to sets of required (sub)package names for each candidate.) * It fails if GITROOT or ABSROOT paths contain spaces. (This is not critical, but it can be certainly fixed somehow. (Dunno how.)) * The differences in directory naming (extra/lsof versus lsof/trunk) caused certain difficulties concerning those prefix/suffix expressions. I may have messed something up. Other remarks and suggestions: * Nearly 100% of corner cases (packages replacing other packges, changes in dependency sets from version to version) cause failures. This means that *most* if not all full system upgrades fail. * The dependency on pacman (and its view of the binary repositories, possibly inconsistent with both ABS and the Git tree) is a problem. * The code badly needs cleanup... * This thing is becoming rather complex. Shouldn't it be implemented in a more suitable language (Perl, Python, ...)? |
srcpac.patch
This task depends upon
Closed by Doug Newgard (Scimmia)
Monday, 15 May 2017, 17:15 GMT
Reason for closing: None
Additional comments about closing: Removed from repos
Monday, 15 May 2017, 17:15 GMT
Reason for closing: None
Additional comments about closing: Removed from repos
1) When SUDO_USER is set, srcpac (or perhaps makepkg) attempts to install missing dependencies using pacman under the restricted user role, which (of course) does not work (at least not in an unattended manner).
2) IMO, when the -b flag is set, the missing build-time dependencies should be *built* (rather than downloaded by pacman) and *optionally* removed (rather than removed automatically). Keeping them is preferable since they will be needed on every single future update of the dependent package and rebuilding or reinstalling them each time serves no purpose. Alternatively, there could be more options, such as
-b == "download missing packages with pacman"
-bb == "build missing packages"
-r == "remove temporarily added build dependencies" (*but* no sooner than at the end of the whole update procedure and only if their removal is still possible (they did not become run-time dependencies in the mean time))
Perhaps I could have a look at the second suggestion, but have no idea how the first one could (should) be dealt with.