Sequence of dependency checks
I think there is a major design flaw in regards to when Packer checks for and pulls in dependencies.
You should always be able to review and edit the PKGBUILD before packer pulls in any new dependencies. This is currently not an option.
Not only is it a nuissance in that packer will pull in dependencies for packages where I mean to edit out of these dependencies before building, but in the case of flawed dependency lists in the PKGBUILD it is actually impossible to build the package via packer.
Case in point, and why I am filing this report: I just tried to pull in evince2, which lists a dependency that does not exists in the repositories and aur. It is fixable if I could edit the PKGBUILD, but since packer searches for the dependency in vain and then exits because it is unsatisfied, I can not do that and now have to build the package by hand.
packer -G evince2 for these 1 in 10000 edge cases.
On Fri, Sep 2, 2011 at 6:31 PM, b9anders < [email protected]>wrote:
I think there is a major design flaw in regards to when Packer checks for and pulls in dependencies.
You should always be able to review and edit the PKGBUILD before packer pulls in any new dependencies. This is currently not an option.
Not only is it a nuissance in that packer will pull in dependencies for packages where I mean to edit out of these dependencies before building, but in the case of flawed dependency lists in the PKGBUILD it is actually impossible to build the package via packer.
Case in point, and why I am filing this report: I just tried to pull in evince2, which lists a dependency that does not exists in the repositories and aur. It is fixable if I could edit the PKGBUILD, but since packer searches for the dependency in vain and then exits because it is unsatisfied, I can not do that and now have to build the package by hand.
Reply to this email directly or view it on GitHub: https://github.com/bruenig/packer/issues/46
This also applies when the PKGUBILD for an AUR package is missing a dependency that needs to be installed. If I edit the PKGBUILD using packer to add the dependency, I would expect it to install the new dependency before attempting to install the package. Instead, it runs makepkg immediately and fails due to the missing dependency.
Again, I am well aware of this. I don't really know what to tell you. It seems like such a fringe case that packer -G should just be the way to go. I don't know what the costs would be to check the PKGBUILD again computationally speaking. If someone wants to put in such functionality and it does not considerably slow it down, I will definitely consider merging it.
On Thu, Nov 24, 2011 at 3:51 PM, Thomas Hebb < [email protected]
wrote:
This also applies when the PKGUBILD for an AUR package is missing a dependency that needs to be installed. If I edit the PKGBUILD using packer to add the dependency, I would expect it to install the new dependency before attempting to install the package. Instead, it runs makepkg immediately and fails due to the missing dependency.
Reply to this email directly or view it on GitHub: https://github.com/bruenig/packer/issues/46#issuecomment-2869089