-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Jonas Karlsson wrote: >>> Dependency files are still a complication though, unless they're >>> changed into a shell-sourceable format. Ideally it would be compatible >>> with existing files though, so I guess that means using a comment. "# >>> :gtk" for "when gtk is enabled"? That would let actual comments still >>> exist, if they're useful to have. >> Dependency files are currently parsed by Python code and it already >> uses a custom syntax (with operators, etc.) -- extending it to put >> flag information, annotation such as "optional", etc., is doable. >> > optional/recommended/required is really needed. And the idea of adding > options/changing status of a dependency depending on flags is a good idea, > the question is how to implement it. Perhaps 'optional :with_gtk' to have > it enabled when 'with_gtk' is used, or even more fine grained: 'optional > with_openssl:recommended with_gnutls:disabled' to have different status > depending on different flags. > >>> I guess that this would also make all enabled dependencies mandatory, >>> which was another issue that came up a while back. >> Looking back, having dependencies accepted/rejected by the user was a >> primitive way of having something like use flags. I'd still like to >> have a power-user-friendly "force" mode, but the default behavior >> could switch to not compile/install if dependencies can't be matched.
Noticing: One important use of forcing an install attempt despite unmatched dependencies is to check if those are indeed (still) needed dependencies. Often there are dependencies for which the build process will _fail_ if unmet. (or perhaps a run-time process for runtime dependencies, including packages not installed from recipe). What would be really neat is if most dependencies were like that(are they?) and annotated as such, so there could be an automatic build-process that checks the accuracy of those dependencies.(for each architecture maybe). (The same process could also check to see if the other required dependencies actually fall under that classification, and say so, if they do.) Naturally there will be some build processes that don't fail when they should, and some things that a human would agree is a dependency even when it can't be checked automatically... if those are few enough, perhaps comments could be put explaining how those dependencies are necessary/important (for the required, not necessarily the optional or recommended dependencies, that is). Isaac P.S. Hoping to (finally) have a GoboLinux-running computer next month, rather than trying again to install a somewhat unfamiliar distribution from source on this old slow powerpc while busy with school :D . Then I should be able to sensibly contribute... -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGPGHaHgcxvIWYTTURArQ7AJ9iu30DekZGh1GR4shyi7hyLwOk3gCfR+Oh 7pIrmShEVJTI1FjbPE5wBYQ= =78/E -----END PGP SIGNATURE----- _______________________________________________ gobolinux-devel mailing list gobolinux-devel@lists.gobolinux.org http://lists.gobolinux.org/mailman/listinfo/gobolinux-devel
