Thomas Bächler wrote:
I want to explicitly ask you about the cons for this feature. What do you think is a hard reason NOT to do it?
1) The depends array in the PKGBUILD no longer represents the information in the package. 2) Lots more dependencies for packages. This will slow pacman down. Also, I believe that provides are slower than depends to resolve. I could be completely wrong there... but that would make this even worse. So it does "hurt" everyone. 3) I believe this should be implemented manually for a very small number of package sets (shells & readline being the main case), but I do not see a general need for this in a large number of packages. Note that this is not much harder that your option of adding a "sodepends" variable - it just requires adding a versioning on the library. 4) How would you negate this to allow a library to be an optdep other than just not using this feature? I am generally against adding extra syntax to PKGBUILDs unless there is a very strong reason to do so. #1 is my primary critisism. Every other option in makepkg that does something magically (removes files, compresses files, etc), has the files they act on defined specifically in makepkg.conf and thus are not really magical at all. We should be able to look at a PKGBUILD and see the information about a package. I know that all the libraries that are magically depends should have their package included in at least the makedepends, but then how do we tell what really are makedeps? Allan