[pacman-dev] makepkg --pkg for selective installation of split packages
Hi, I completely missed the discussion in September about removing the "--pkg" option from makepkg. Without that option, "makepkg -irs" can only be used to install all packages from a split PKGBUILD, but a user often wants to install just one package (e.g [1]). Makepkg's automatic dependency resolution and installation is very useful for automation, and scripting "pacman -U" requires assumptions about expected package names that are likely error-prone and thus not a viable alternative. I opened a bug report about this before seeing the thread. I bring it up here for further discussion as this is where its removal was discussed. Regards, Xyne [1] https://bbs.archlinux.org/viewtopic.php?pid=1604418#p1604418
On Sun, Feb 14, 2016 at 08:25:23PM +0000, Xyne wrote:
Hi,
I completely missed the discussion in September about removing the "--pkg" option from makepkg. Without that option, "makepkg -irs" can only be used to install all packages from a split PKGBUILD, but a user often wants to install just one package (e.g [1]). Makepkg's automatic dependency resolution and installation is very useful for automation, and scripting "pacman -U" requires assumptions about expected package names that are likely error-prone and thus not a viable alternative.
Note that you can now also use makepkg to list the names of the packages that it would generate, using the --packagelist flag.
I opened a bug report about this before seeing the thread. I bring it up here for further discussion as this is where its removal was discussed.
Regards, Xyne
[1] https://bbs.archlinux.org/viewtopic.php?pid=1604418#p1604418
On 2016-02-14 15:31 -0500 Dave Reisner wrote:
Note that you can now also use makepkg to list the names of the packages that it would generate, using the --packagelist flag.
I am going to use that as a workaround but even after splitting apart the components (pkgname, pkgver, arch) and making sure that the name matches, it will require assumptions about the package archive extension (or sourcing of makepkg.conf, but that requires knowledge of which makepkg.conf was used to be rigorous). Nothing comes close to the cleanliness of the --pkg option. Incidentally, that option was also useful to avoid storing unwanted packages at PKGDEST.
On 2016-02-14 21:37 +0000 Xyne wrote:
On 2016-02-14 15:31 -0500 Dave Reisner wrote:
Note that you can now also use makepkg to list the names of the packages that it would generate, using the --packagelist flag.
I am going to use that as a workaround but even after splitting apart the components (pkgname, pkgver, arch) and making sure that the name matches, it will require assumptions about the package archive extension (or sourcing of makepkg.conf, but that requires knowledge of which makepkg.conf was used to be rigorous). Nothing comes close to the cleanliness of the --pkg option.
Incidentally, that option was also useful to avoid storing unwanted packages at PKGDEST.
Implementing the workaround right now I've noticed that another issue with the separate invocation of pacman -U is that any dependencies installed via "makepkg -rs" are removed and then re-installed during installation with pacman, while omitting "-r" will leave makedeps.
Implementing the workaround right now I've noticed that another issue with the separate invocation of pacman -U is that any dependencies installed via "makepkg -rs" are removed and then re-installed during installation with pacman, while omitting "-r" will leave makedeps.
Another annoying point: makepkg -rs with DESTDIR detects previously built packages but no longer recreates the symlink in the working directory so any subsequent pacman -U command needs to determine where the DESTDIR is and install from there.
On 15/02/16 08:31, Xyne wrote:
On 2016-02-14 21:37 +0000 Xyne wrote:
On 2016-02-14 15:31 -0500 Dave Reisner wrote:
Note that you can now also use makepkg to list the names of the packages that it would generate, using the --packagelist flag.
I am going to use that as a workaround but even after splitting apart the components (pkgname, pkgver, arch) and making sure that the name matches, it will require assumptions about the package archive extension (or sourcing of makepkg.conf, but that requires knowledge of which makepkg.conf was used to be rigorous). Nothing comes close to the cleanliness of the --pkg option.
Incidentally, that option was also useful to avoid storing unwanted packages at PKGDEST.
Implementing the workaround right now I've noticed that another issue with the separate invocation of pacman -U is that any dependencies installed via "makepkg -rs" are removed and then re-installed during installation with pacman, while omitting "-r" will leave makedeps.
pamcan -U deals with dependency resolution.
Implementing the workaround right now I've noticed that another issue with the separate invocation of pacman -U is that any dependencies installed via "makepkg -rs" are removed and then re-installed during installation with pacman, while omitting "-r" will leave makedeps.
pamcan -U deals with dependency resolution.
Yeah, but lets say you want to install foo with depends=(bar baz lulu) makedepends=(this that whatever) makepkg -rs installs bar, baz, lulu, this, that and whatever, builds the package, then removes all of them. Subsequent pacman -U then re-installs bar, baz, and lulu. Even if the packages are small with no side-effects via install scripts, that is inefficient. If they are large and/or have side-effects (e.g. updating system databases, font caches, etc) then it is very inefficient.
Just to follow up, I came to the conclusion that there is no viable workaround for all scenarios (e.g. when PKGDEST is set) so I ended up patching makepkg to restore the --pkg option. It only affects the installation. I also added the option "--pconfig" to pass a custom configuration file to pacman (which required changing PACMAN_OPTS to an array to avoid potential word expansion). The patch is small. If anyone is interested, you can find it in the current bauerbill source tarball [1]. If there is a chance of inclusion upstream then I can rework it and submit it as a Git patch. [1] http://xyne.archlinux.ca/projects/bauerbill/src/bauerbill-2016.2.15.tar.xz
On 15/02/16 11:54, Xyne wrote:
Just to follow up, I came to the conclusion that there is no viable workaround for all scenarios (e.g. when PKGDEST is set) so I ended up patching makepkg to restore the --pkg option. It only affects the installation. I also added the option "--pconfig" to pass a custom configuration file to pacman (which required changing PACMAN_OPTS to an array to avoid potential word expansion).
The patch is small. If anyone is interested, you can find it in the current bauerbill source tarball [1]. If there is a chance of inclusion upstream then I can rework it and submit it as a Git patch.
[1] http://xyne.archlinux.ca/projects/bauerbill/src/bauerbill-2016.2.15.tar.xz
No chance the full patch will be accepted. But the changing PACMAN_OPTS to an array should probably be done. A
On 2016-02-15 15:05 +1000 Allan McRae wrote:
No chance the full patch will be accepted. But the changing PACMAN_OPTS to an array should probably be done.
Here's a patch for converting PACMAN_OPTS to an array (if this list accepts attachments). I'll post a link if not. Any change of getting --pkg restored just for selecting which package to install? It would only affect the package loop in the "install_package" function. Incidentally, "pkg:" is still in the OPT_LONG array.
Any change *chance*
participants (3)
-
Allan McRae
-
Dave Reisner
-
Xyne