[pacman-dev] Delete just $pkgdir instead of whole $pkgdirbase
Hi. makepkg deletes the whole $pkgdirbase directory before starting build(). https://github.com/elieux/pacman/blob/upstream/scripts/makepkg.sh.in#L3460 I propose a change to delete just $pkgdir, and an addition of similar code before starting package*(). I don't see any downside to this (except for the time it takes to implement the change) and I give two reasons for the change: Reason 1: in case $pkgdirbase is a symlink, it gets re-created as a regular directory, which is probably unwanted behavior. The MSYS2 guys even have a patch for this. https://github.com/elieux/pacman/blob/master/scripts/makepkg.sh.in#L3378-338... Reason 2: in case makepkg is ran twice in the same directory (but with different configurations and different $pkgname), the second run deletes the $pkgdirbase of the first run, but sometimes it's beneficial to inspect the $pkgdir after makepkg has finished. This may seem as an obscure use-case, but it's very common with the MSYS2 project. https://github.com/elieux/MSYS2-packages/blob/master/pacman/makepkg-mingw (Since this seems to be a fairly easy thing to change, I may even prepare a patch myself.) -- David Macek
On 20/02/15 10:59, David Macek wrote:
Hi.
makepkg deletes the whole $pkgdirbase directory before starting build(). https://github.com/elieux/pacman/blob/upstream/scripts/makepkg.sh.in#L3460
I propose a change to delete just $pkgdir, and an addition of similar code before starting package*(). I don't see any downside to this (except for the time it takes to implement the change) and I give two reasons for the change:
Reason 1: in case $pkgdirbase is a symlink, it gets re-created as a regular directory, which is probably unwanted behavior. The MSYS2 guys even have a patch for this. https://github.com/elieux/pacman/blob/master/scripts/makepkg.sh.in#L3378-338...
Reason 2: in case makepkg is ran twice in the same directory (but with different configurations and different $pkgname), the second run deletes the $pkgdirbase of the first run, but sometimes it's beneficial to inspect the $pkgdir after makepkg has finished. This may seem as an obscure use-case, but it's very common with the MSYS2 project. https://github.com/elieux/MSYS2-packages/blob/master/pacman/makepkg-mingw
(Since this seems to be a fairly easy thing to change, I may even prepare a patch myself.)
Just a one line patch is needed: - rm -rf "$pkgdirbase" + rm -rf "$pkgdirbase/*" The MSys2 patch is wrong (the empty permissions does not get reinstated if the directory is already there). Someone submit that for me... Allan
On 23. 2. 2015 10:31, Allan McRae wrote:
On 20/02/15 10:59, David Macek wrote:
Hi.
makepkg deletes the whole $pkgdirbase directory before starting build(). https://github.com/elieux/pacman/blob/upstream/scripts/makepkg.sh.in#L3460
I propose a change to delete just $pkgdir, and an addition of similar code before starting package*(). I don't see any downside to this (except for the time it takes to implement the change) and I give two reasons for the change:
Reason 1: in case $pkgdirbase is a symlink, it gets re-created as a regular directory, which is probably unwanted behavior. The MSYS2 guys even have a patch for this. https://github.com/elieux/pacman/blob/master/scripts/makepkg.sh.in#L3378-338...
Reason 2: in case makepkg is ran twice in the same directory (but with different configurations and different $pkgname), the second run deletes the $pkgdirbase of the first run, but sometimes it's beneficial to inspect the $pkgdir after makepkg has finished. This may seem as an obscure use-case, but it's very common with the MSYS2 project. https://github.com/elieux/MSYS2-packages/blob/master/pacman/makepkg-mingw
(Since this seems to be a fairly easy thing to change, I may even prepare a patch myself.)
Just a one line patch is needed:
- rm -rf "$pkgdirbase" + rm -rf "$pkgdirbase/*"
The MSys2 patch is wrong (the empty permissions does not get reinstated if the directory is already there).
Someone submit that for me...
This only solves case 1, not case 2, which is actually more important to me. -- David Macek
On 24/02/15 01:03, David Macek wrote:
On 23. 2. 2015 10:31, Allan McRae wrote:
On 20/02/15 10:59, David Macek wrote:
Hi.
makepkg deletes the whole $pkgdirbase directory before starting build(). https://github.com/elieux/pacman/blob/upstream/scripts/makepkg.sh.in#L3460
I propose a change to delete just $pkgdir, and an addition of similar code before starting package*(). I don't see any downside to this (except for the time it takes to implement the change) and I give two reasons for the change:
Reason 1: in case $pkgdirbase is a symlink, it gets re-created as a regular directory, which is probably unwanted behavior. The MSYS2 guys even have a patch for this. https://github.com/elieux/pacman/blob/master/scripts/makepkg.sh.in#L3378-338...
Reason 2: in case makepkg is ran twice in the same directory (but with different configurations and different $pkgname), the second run deletes the $pkgdirbase of the first run, but sometimes it's beneficial to inspect the $pkgdir after makepkg has finished. This may seem as an obscure use-case, but it's very common with the MSYS2 project. https://github.com/elieux/MSYS2-packages/blob/master/pacman/makepkg-mingw
(Since this seems to be a fairly easy thing to change, I may even prepare a patch myself.)
Just a one line patch is needed:
- rm -rf "$pkgdirbase" + rm -rf "$pkgdirbase/*"
The MSys2 patch is wrong (the empty permissions does not get reinstated if the directory is already there).
Someone submit that for me...
This only solves case 1, not case 2, which is actually more important to me.
I need case two explained to me more. Why are you not using two PKGBUILDs?
On 23. 2. 2015 16:23, Allan McRae wrote:
I need case two explained to me more. Why are you not using two PKGBUILDs?
Basically, the situation with "mingw" packages (which contain native Windows programs, while "msys2" packaged programs run on a POSIX emulation layer) is kind of like multilib, but 32 bits are equally important as 64 bits. In interest of de-duplication, there is always only one PKGBUILD per package, for both mingw32 and mingw64. More detailed explanation: As you may know, 64-bit Windows are capable of running 32-bit software by default, and a lot of existing software has not been ported to 64 bits. For msys2, users are expected to install the variant with same amount of bits as the host Windows and packages are chosen according to the `arch` field. But since it's desirable to allow users to install both bitness variants of mingw packages, these have `arch=any` and are differentiated by a prefix in package name. As there is no correct or default amount of bits, both package variants are built with the same PKGBUILD using several envvars to switch between the variants. In order to promote always building both variants, the makepkg-mingw wrapper invokes the two builds in succession by default. I hope my explanation helps. Note that although I'm interested in a better way to organize these things, it's unlikely anything will change in foreseeable future (probably not until 32-bit Windows dies out). -- David Macek
On 24/02/15 01:52, David Macek wrote:
On 23. 2. 2015 16:23, Allan McRae wrote:
I need case two explained to me more. Why are you not using two PKGBUILDs?
Basically, the situation with "mingw" packages (which contain native Windows programs, while "msys2" packaged programs run on a POSIX emulation layer) is kind of like multilib, but 32 bits are equally important as 64 bits. In interest of de-duplication, there is always only one PKGBUILD per package, for both mingw32 and mingw64.
More detailed explanation: As you may know, 64-bit Windows are capable of running 32-bit software by default, and a lot of existing software has not been ported to 64 bits. For msys2, users are expected to install the variant with same amount of bits as the host Windows and packages are chosen according to the `arch` field. But since it's desirable to allow users to install both bitness variants of mingw packages, these have `arch=any` and are differentiated by a prefix in package name. As there is no correct or default amount of bits, both package variants are built with the same PKGBUILD using several envvars to switch between the variants. In order to promote always building both variants, the makepkg-mingw wrapper invokes the two builds in succession by default.
I hope my explanation helps.
Note that although I'm interested in a better way to organize these things, it's unlikely anything will change in foreseeable future (probably not until 32-bit Windows dies out).
I dislike the idea of a non-empty $pkgdir at the start of packaging so am not convinced about this yet. Why would you not change where the $pkgdir symlink points as part of your script that does the needed changes and builds all the package variants? Allan
On 23. 2. 2015 18:11, Allan McRae wrote:
I dislike the idea of a non-empty $pkgdir at the start of packaging so am not convinced about this yet.
Just to be sure, do you mean $pkgdir, or $pkgdirbase? My proposition was retaining ./pkg/whatever-pkg-dirs, but still cleaning ./pkg/current-pkg-dir before package().
Why would you not change where the $pkgdir symlink points as part of your script that does the needed changes and builds all the package variants?
$pkgdirbase doesn't need to be a symlink, the wrapper script doesn't currently link anything by itself. Moreover, symlinks are actually disabled by default in MSYS2 due to various difficulties, and `ln -s` creates copies instead. -- David Macek
On 24/02/15 05:27, David Macek wrote:
On 23. 2. 2015 18:11, Allan McRae wrote:
I dislike the idea of a non-empty $pkgdir at the start of packaging so am not convinced about this yet.
Just to be sure, do you mean $pkgdir, or $pkgdirbase? My proposition was retaining ./pkg/whatever-pkg-dirs, but still cleaning ./pkg/current-pkg-dir before package().
I meant $pkgbasedir - I'm stuck back in the old days!
Why would you not change where the $pkgdir symlink points as part of your script that does the needed changes and builds all the package variants?
$pkgdirbase doesn't need to be a symlink, the wrapper script doesn't currently link anything by itself. Moreover, symlinks are actually disabled by default in MSYS2 due to various difficulties, and `ln -s` creates copies instead.
OK - rename the $pkgbasedir directory instead. Or just extract the package tarballs when you want to look at the package files. Allan
participants (2)
-
Allan McRae
-
David Macek