My issue is with the sickgear package, where the maintainer has put the "depends" variable in the package() function. packer simply sources the PKGBUILD files and then uses variables in its env to filter the dependencies. This creates an issue for PKGBUILDs like sickgear's, as the package() function isn't actually execute, so the "depends" variable isn't sourced into the environment.
@keenerd not quite sure how to best solve this. I get the maintainers putting the depends array inside the package function. People not actually wishing to package shouldn't have to care about dependencies until the package() function is actually called. The AUR also seems to support this (unless dependency information is entered manually). Are these issues you're willing to catch in the code, or do you think package maintainers should put their depends variables in the top scope of their PKGBUILDs?
My issue is with the sickgear package, where the maintainer has put the "depends" variable in the
package()function.packersimply sources the PKGBUILD files and then uses variables in itsenvto filter the dependencies. This creates an issue for PKGBUILDs like sickgear's, as thepackage()function isn't actually execute, so the "depends" variable isn't sourced into the environment.@keenerd not quite sure how to best solve this. I get the maintainers putting the depends array inside the package function. People not actually wishing to package shouldn't have to care about dependencies until the package() function is actually called. The AUR also seems to support this (unless dependency information is entered manually). Are these issues you're willing to catch in the code, or do you think package maintainers should put their depends variables in the top scope of their PKGBUILDs?