[arch-dev-public] texlive-bin binary doesn't match PKGBUILD
Somehow the texlive-bin PKGBUILD doesn't provide the same binary package that is in the repository. I just committed a gnome-unstable directory with 3 patches that fixes build against poppler 0.12, but building it with makechrootpkg results in a lot of missing binaries. Also, I couldn't build texlive-bin without adding some force commands to ln and rm.
Jan de Groot wrote:
Somehow the texlive-bin PKGBUILD doesn't provide the same binary package that is in the repository. I just committed a gnome-unstable directory with 3 patches that fixes build against poppler 0.12, but building it with makechrootpkg results in a lot of missing binaries. Also, I couldn't build texlive-bin without adding some force commands to ln and rm.
Thanks for reporting this Jan. I'll happily loot into this. But can you send me some more details first? Here are the facts from my side: texlive-bin 2009.4-2 was indeed created with "makepkg -R" on the basis of the previous build (pkgrel=1) because I only needed to add two missing symlinks for texlua and texluac (see FS#16486) and did not feel like rebuilding the whole goddam thing for something as simple as that (ca. 30 minutes of compilation at full processor last costs a lot of electricity you know ;) and my fans get real noisy too!)... So yes, I did fix that by hand: I unpacked the previously built packages under $pkgdir, created the symlinks, added the corresponding missing lines in the PKGBUILD, and then repackaged. I can assure you that the previous build (2009.4-1) was generated from the PKGBUILD then in trunk. But it was NOT built with makechrootpkg. Sometimes (rarely) makechroot is not a good idea. I know that building subversion and gvim with makechroot can yield incorrect packages. In the particular case of texlive-bin, which is very complex, I need to be in full control and a chroot environment does not provide this condition. But I am open to your criticism if you think this is not a good approach ;) Yet I am nevertheless surprised that texlive-bin does not build well with makechrootpkg. I certainly does in a normal environment. F
On Mon, 2009-10-12 at 10:08 +0200, Firmicus wrote:
Jan de Groot wrote:
Somehow the texlive-bin PKGBUILD doesn't provide the same binary package that is in the repository. I just committed a gnome-unstable directory with 3 patches that fixes build against poppler 0.12, but building it with makechrootpkg results in a lot of missing binaries. Also, I couldn't build texlive-bin without adding some force commands to ln and rm.
Thanks for reporting this Jan. I'll happily loot into this. But can you send me some more details first?
Here are the facts from my side:
texlive-bin 2009.4-2 was indeed created with "makepkg -R" on the basis of the previous build (pkgrel=1) because I only needed to add two missing symlinks for texlua and texluac (see FS#16486) and did not feel like rebuilding the whole goddam thing for something as simple as that (ca. 30 minutes of compilation at full processor last costs a lot of electricity you know ;) and my fans get real noisy too!)...
So yes, I did fix that by hand: I unpacked the previously built packages under $pkgdir, created the symlinks, added the corresponding missing lines in the PKGBUILD, and then repackaged. I can assure you that the previous build (2009.4-1) was generated from the PKGBUILD then in trunk. But it was NOT built with makechrootpkg. Sometimes (rarely) makechroot is not a good idea. I know that building subversion and gvim with makechroot can yield incorrect packages. In the particular case of texlive-bin, which is very complex, I need to be in full control and a chroot environment does not provide this condition. But I am open to your criticism if you think this is not a good approach ;)
Yet I am nevertheless surprised that texlive-bin does not build well with makechrootpkg. I certainly does in a normal environment.
The fixes were minor. It took me several rebuilds to find this out, but here's a list: - The symlinks you created weren't in the PKGBUILD correctly, I added the correct ones, but didn't remove the wrong ones - The command that generates all the symlinks depends on texlive-bin being installed on the system, I fixed it by adding $pkgdir/usr/bin to $PATH Besides the two fixes, nothing special was done to the package.
Jan de Groot a écrit :
On Mon, 2009-10-12 at 10:08 +0200, Firmicus wrote:
Jan de Groot wrote:
Somehow the texlive-bin PKGBUILD doesn't provide the same binary package that is in the repository. I just committed a gnome-unstable directory with 3 patches that fixes build against poppler 0.12, but building it with makechrootpkg results in a lot of missing binaries. Also, I couldn't build texlive-bin without adding some force commands to ln and rm.
Thanks for reporting this Jan. I'll happily loot into this. But can you send me some more details first?
Here are the facts from my side:
texlive-bin 2009.4-2 was indeed created with "makepkg -R" on the basis of the previous build (pkgrel=1) because I only needed to add two missing symlinks for texlua and texluac (see FS#16486) and did not feel like rebuilding the whole goddam thing for something as simple as that (ca. 30 minutes of compilation at full processor last costs a lot of electricity you know ;) and my fans get real noisy too!)...
So yes, I did fix that by hand: I unpacked the previously built packages under $pkgdir, created the symlinks, added the corresponding missing lines in the PKGBUILD, and then repackaged. I can assure you that the previous build (2009.4-1) was generated from the PKGBUILD then in trunk. But it was NOT built with makechrootpkg. Sometimes (rarely) makechroot is not a good idea. I know that building subversion and gvim with makechroot can yield incorrect packages. In the particular case of texlive-bin, which is very complex, I need to be in full control and a chroot environment does not provide this condition. But I am open to your criticism if you think this is not a good approach ;)
Yet I am nevertheless surprised that texlive-bin does not build well with makechrootpkg. I certainly does in a normal environment.
The fixes were minor. It took me several rebuilds to find this out, but here's a list: - The symlinks you created weren't in the PKGBUILD correctly, I added the correct ones, but didn't remove the wrong ones
why?
- The command that generates all the symlinks depends on texlive-bin being installed on the system, I fixed it by adding $pkgdir/usr/bin to $PATH Besides the two fixes, nothing special was done to the package.
OK, I have just examined your fixes with svn diff: thanks a lot! F
On Mon, 2009-10-12 at 11:37 +0200, Firmicus wrote:
- The symlinks you created weren't in the PKGBUILD correctly, I added the correct ones, but didn't remove the wrong ones
why?
Because I didn't know what you wanted to do with the wrong ones. I thought they had some meaning, but now I realize they were just plain wrong.
Jan de Groot a écrit :
On Mon, 2009-10-12 at 11:37 +0200, Firmicus wrote:
- The symlinks you created weren't in the PKGBUILD correctly, I
added
the correct ones, but didn't remove the wrong ones
why?
Because I didn't know what you wanted to do with the wrong ones. I thought they had some meaning, but now I realize they were just plain wrong.
plain wrong indeed :) I've deleted those two lines in trunk
Firmicus wrote:
Sometimes (rarely) makechroot is not a good idea. I know that building subversion and gvim with makechroot can yield incorrect packages.
I have built subversion in a chroot... in fact the current subversion packages were done so and they appear to be working. If a package does not build in makechrootpkg, it is either a bug in that or the PKGBUILD and a bug report is necessary. Allan
participants (3)
-
Allan McRae
-
Firmicus
-
Jan de Groot