Re: [gentoo-dev] RFC: optinal run time dependencies
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 18/07/2011 05:45 μμ, Ciaran McCreesh wrote: > On Mon, 18 Jul 2011 17:25:08 +0300 > Markos Chandras wrote: >>> If you have suggested dependencies, you don't need to use >>> pkg_postinst, since suggested dependencies are better. >>> >> You may need some extra text to explain why these dependencies are >> needed, or what kind of runtime functionality they provide > > No, that's part of the suggestion itself (and is something that's > needed for blockers too). One fairly elegant way of doing it is: > > http://exherbo.org/docs/exheres-for-smarties.html#annotations > >> or how to enable/disable them etc. > > And that's part of how to use the package manager. > So we are not just talking about a new variable (SDEPEND) but about a new notation as well. To be honest, I like the exherbo approach. I would like the council to include this topic in the upcoming agenda - -- Regards, Markos Chandras / Gentoo Linux Developer / Key ID: B4AFF2C2 -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (GNU/Linux) iQIcBAEBCgAGBQJOJE6IAAoJEPqDWhW0r/LCF4AP/Rmzui1Y+MFhYygvKAlKPcLV tQ7xTELovgtO/9n8VnyV+l3HJn7itPq2ixpGa9qrCumch2/Qa0Prsit0CKc3+N0K tOPNuTB+hrI6PZ6vNGL5vc2qjUBIm2ykd6RVYA2RTaxa9UdiUTaxzZ9z704y/4y3 CJqb65/ytYvZTqXUIL/w3iJ5ZaZkwR5O8/+GfinA9ubf0yoSP47i9cwBMK6SV8K2 K5ZaHJxdOl4tP+3HK0vk2zDfvlyfgzA4rkds4u+DFKCMPGcJucmi5kiPelMuUqu8 BFMolq7nXA8QAy7xuG0SL7MojW2oGT6lRNX2l/FO/rMrs8+3qmzNzelzzUE85q+g VPAMyJUrFPZIxR2oYT2gdEl1nEOomot7hEWQrU3AO89kgnORFHtAlPMIb4lOGvSF o/Wtcbli0vCkEWKSuqAWvw7QXJiSxuL1abxfva1sSTFYa60Z5/WLOIYq5XvcAteo oN0KQj/L6udrsDsuUJofnFSUTjKyIXFb7uc/Ism7zfBiiWLK+5fgo8ps5yJLda1i 7DmOk12KJ3Jtsog6Iggm+wbO38UtwZxOh1StKQX5JW4+CXXLXD/aru70ZXeK91uQ t4mkDG5zn5SvQVL3hOsD3tAd99p/ISeHmo72SB4+IczKzE7SsFX8VqRIJ2C561mj xTNO1Nn/K3AOg//XULdH =tCXI -END PGP SIGNATURE-
Re: [gentoo-dev] RFC: optinal run time dependencies
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Mon, 18 Jul 2011 17:25:08 +0300 Markos Chandras wrote: > > If you have suggested dependencies, you don't need to use > > pkg_postinst, since suggested dependencies are better. > > > You may need some extra text to explain why these dependencies are > needed, or what kind of runtime functionality they provide No, that's part of the suggestion itself (and is something that's needed for blockers too). One fairly elegant way of doing it is: http://exherbo.org/docs/exheres-for-smarties.html#annotations > or how to enable/disable them etc. And that's part of how to use the package manager. - -- Ciaran McCreesh -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (GNU/Linux) iEYEARECAAYFAk4kRwIACgkQ96zL6DUtXhFLUQCgzcaXuwpnTdYIpT683xTJlQ/e liQAoLTbYFcjmQELoLbtfMT39lm6vanS =+Cfq -END PGP SIGNATURE-
Re: [gentoo-dev] RFC: optinal run time dependencies
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 18/07/2011 05:02 ??, Ciaran McCreesh wrote: > On Mon, 18 Jul 2011 13:44:27 +0300 > Markos Chandras wrote: >> Whilst I like the new variable approach, I think this adds too much >> overhead to the already bloated ebuild writing. >> pkg_postinst messages include not only the optional dependencies but >> other useful messages as well. So you may end up using both SDEPEND >> and pkg_postinst. > > If you have suggested dependencies, you don't need to use pkg_postinst, > since suggested dependencies are better. > You may need some extra text to explain why these dependencies are needed, or what kind of runtime functionality they provide or how to enable/disable them etc. - -- Regards, Markos Chandras / Gentoo Linux Developer / Key ID: B4AFF2C2 -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (GNU/Linux) iQIcBAEBCgAGBQJOJEJEAAoJEPqDWhW0r/LCiqEP/09VxE4xHbCfE+TInxd2Y5c4 8fK4B7CdbZRLMKtAZAcLM9+AvSntkIWz03rI5WRglQRKX13LFU2kobB3ZyVlK4lD Gd/GxKr5N37b+wNQ076EH/JGcRwJBYNL2YlQfcd1M7HcUBhxx2GCODw7fJbGM8Wv 33g7RNdsD/J6Z3w15xB/1S0klpBD28xmGU55romqJBqeMSLGJoxCMcC+6uC98Kpy 0+dpXw/VUoUJwEN8TyCAhL2JY0nFYd1z2LllJY7JNuQ29sN+Z8aJA76P45H2Wr+V Ib9750NHwhrsfvKBxAk7b7+u/zUyryXnUXZ3b4A8DIhkRlWGIi3Uxo0zOCvB+fbj 20dkpscwkz2LK6Av+DVFWs0hj4na1i2x+RYgUxvsqBmlhvbbjPY4bmFgh+gY0zKO mFqMgV1YZygZnFcYafelloo9eGYLjS7W/0tCEvNvTmRIueX+Aee+vRpAgeWF3YyE 5yvoYuxLCSJCXRKZXt9PH1krR11TJn1bLy6gTUsw2uYzjBnpoJ5ixh3tn1nGxEQI k3Epc8mgaCMe6KpqbmIxy2geHVCtdnWpgfiib9JnVKqGUsWbZeQX+BqWYRuvQzhE fLkwbUjI7PXSjAn3O5XAoBi4VMal9hWD11VtOTHaFRiDkoP6oOYfx4ecLlZ+fAhQ ty8/mkMo7Mrqv2qd/WQL =RNmT -END PGP SIGNATURE-
Re: [gentoo-dev] RFC: optinal run time dependencies
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Mon, 18 Jul 2011 13:44:27 +0300 Markos Chandras wrote: > Whilst I like the new variable approach, I think this adds too much > overhead to the already bloated ebuild writing. > pkg_postinst messages include not only the optional dependencies but > other useful messages as well. So you may end up using both SDEPEND > and pkg_postinst. If you have suggested dependencies, you don't need to use pkg_postinst, since suggested dependencies are better. - -- Ciaran McCreesh -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (GNU/Linux) iEYEARECAAYFAk4kPPkACgkQ96zL6DUtXhEEYQCcCIy7HSy98qPQZvti1uTamua8 CjQAoLOqLJgC4jz6+ZhLfxsqL9TwJ9mz =rq0a -END PGP SIGNATURE-
Re: [gentoo-dev] RFC: optinal run time dependencies
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 29/06/2011 05:27 ??, Donnie Berkholz wrote: > On 14:38 Tue 28 Jun , Peter Volkov wrote: >> 1. add a use flag to control runtime dependency >> 2. add elog message into pkg_postinst to notify users that some >> features depend on installing package A, B, etc. > > I've got a suggestion that builds a little bit on what both you and > Ciaran have said. > > The UI could probably be clearer if we added a new dependency type like > SDEPEND (suggested deps) with USE flags for different features. That > would enable portage to show things in a special way if it knew about > SDEPEND. Yet it wouldn't do anything weird that broke backwards > compatibility or produced strange output from noncompliant PMs (like USE > flag modifications). > > Then PMs would be free to implement their own logic for how to handle > it. For Portage, I'd like to see a few cases: > > 1) If a package is installed, assume it's desired, as Ciaran proposed. > > 2) Add a way to determine whether to install all/none/groups of them, >w/ configuration in /etc/portage/package.suggestions/. Probably CPV >followed by the setting (all, none, specific groups, or specific >CPVs). Add an option similar to --autounmask that would let Portage >write to this file. > > 3) Something like the --take argument and friends that Ciaran mentioned >seems reasonable (perhaps --accept-suggestion, w/ a short option to >save typing). > > Problems? Other thoughts? > Whilst I like the new variable approach, I think this adds too much overhead to the already bloated ebuild writing. pkg_postinst messages include not only the optional dependencies but other useful messages as well. So you may end up using both SDEPEND and pkg_postinst. - -- Regards, Markos Chandras / Gentoo Linux Developer / Key ID: B4AFF2C2 -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (GNU/Linux) iQIcBAEBCgAGBQJOJA6KAAoJEPqDWhW0r/LCl60QALFbejmtunZYdKhfcVyqLZLH b/0LvYZtowK5/63Mma2T5z+ioJ/mYqSwQty1dHbcCXcLM0hcw4IEIkOKVslXfQZ6 3bCeIOmxOld99wSg4pRG1IDOhQl5rBSQf7TGfGTwIApKsMvl9SvSxKvHtePdM+pT derywLu+OtERTaunrbqNawRG3Xvun3N4bFYcLETCUYFSU8NwKJ6+/C105NV8EvKc 9MvxQgt3NrYwwhXepKk2cu3vwWcolfmf7otpFsCp+exrbVTfTQdH2KA4CYKH7ItN Bv33IxxmST32jzJWAi1lzf5kAc1/NmDSPKZCbYhJvGGz7hCpkbtY0efBOm/JoQVZ gHgxghOclA/F0kA5fkJIX+poIKRIHOyuUEbNeLZ+9a/ANz6wwrrBmnhATxPfMtgB yLXuYHtaKPMvHUh8ZHdAkgS7c4obMYgAxjFV8EPfj+bqECIDTvLauOfHhCg8YklG YhCPj691b1rG6I1kz65nhR+xx7bSUM8nEzs3tUPxCF6BJoLGUbIJRqE9h5w4BVte Io58X6d6bY8jfrkxQ0RX4CdEasiAuhr0NlDq7Vj2eHDKeqCwSGK+gb33bo/x0IpT cwrjRL2PBSQMnHiXdJOTOp1PLO6vmE5eVNwE0P89UC4zZpC0cBqpnaZKnoWRh6lO FZemGA6/xtd+XrNx4rrM =x5XU -END PGP SIGNATURE-
Re: [gentoo-dev] RFC: optinal run time dependencies
After some thinking, I'd like to re-state the USE_EXPAND variant as having the following advantages: 1) backwards compatible -- we can make the new feature optional for older EAPIs, making it useful for older ebuilds as well. If a PM doesn't support it, it will just treat them as ordinary USE; 2) almost no new learning for users -- as users set flags now, they can set optional deps; 3) dep (or dep groups) would be named by features and not only package names, 4) easy grouping of optional dependencies -- if a particular feature requires more than one optional package, 5) ability to use existing infra -- REQUIRED_USE, metadata.xml for descriptions. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] RFC: optinal run time dependencies
On 14:38 Tue 28 Jun , Peter Volkov wrote: > 1. add a use flag to control runtime dependency > 2. add elog message into pkg_postinst to notify users that some > features depend on installing package A, B, etc. I've got a suggestion that builds a little bit on what both you and Ciaran have said. The UI could probably be clearer if we added a new dependency type like SDEPEND (suggested deps) with USE flags for different features. That would enable portage to show things in a special way if it knew about SDEPEND. Yet it wouldn't do anything weird that broke backwards compatibility or produced strange output from noncompliant PMs (like USE flag modifications). Then PMs would be free to implement their own logic for how to handle it. For Portage, I'd like to see a few cases: 1) If a package is installed, assume it's desired, as Ciaran proposed. 2) Add a way to determine whether to install all/none/groups of them, w/ configuration in /etc/portage/package.suggestions/. Probably CPV followed by the setting (all, none, specific groups, or specific CPVs). Add an option similar to --autounmask that would let Portage write to this file. 3) Something like the --take argument and friends that Ciaran mentioned seems reasonable (perhaps --accept-suggestion, w/ a short option to save typing). Problems? Other thoughts? -- Thanks, Donnie Donnie Berkholz Sr. Developer, Gentoo Linux Blog: http://dberkholz.com pgpEUroOHMuW9.pgp Description: PGP signature
Re: [gentoo-dev] RFC: optinal run time dependencies
On Tue, 28 Jun 2011 12:19:43 +0100 Ciaran McCreesh wrote: > On Tue, 28 Jun 2011 13:14:40 +0200 > Michał Górny wrote: > > On Tue, 28 Jun 2011 12:03:28 +0100 > > Ciaran McCreesh wrote: > > > Have you seen how Exherbo solved the same problem? exheres-0 has > > > 'suggested' and 'recommended' dependencies, which are variations > > > on post dependencies. Suggested dependencies are displayed (along > > > with a description explaining what they do for the packages > > > suggesting them) but not taken by default, and recommended > > > dependencies are taken (but shown as just being recommended) > > > unless the user says not to. > > > > Seems to me like just another configuration file for user to cope > > with. > > You obviously didn't pay attention, since the configuration file is > the least relevant bit of the whole thing. If you really think that > too many configuration files is a bigger problem than making > reinstalls suddenly not reinstall stuff, though, then tracking > not-taken suggestions is trivial. > > Having real world experience with all of this, I can assure you that > configuration files are not what cause user difficulties. Ah, I missed the point of not having to rebuild packages. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] RFC: optinal run time dependencies
On Tue, 28 Jun 2011 13:14:40 +0200 Michał Górny wrote: > On Tue, 28 Jun 2011 12:03:28 +0100 > Ciaran McCreesh wrote: > > Have you seen how Exherbo solved the same problem? exheres-0 has > > 'suggested' and 'recommended' dependencies, which are variations on > > post dependencies. Suggested dependencies are displayed (along with > > a description explaining what they do for the packages suggesting > > them) but not taken by default, and recommended dependencies are > > taken (but shown as just being recommended) unless the user says > > not to. > > Seems to me like just another configuration file for user to cope > with. You obviously didn't pay attention, since the configuration file is the least relevant bit of the whole thing. If you really think that too many configuration files is a bigger problem than making reinstalls suddenly not reinstall stuff, though, then tracking not-taken suggestions is trivial. Having real world experience with all of this, I can assure you that configuration files are not what cause user difficulties. > We can achieve the same results with the special USE Peter suggested > and USE defaults, using the same configuration mechanism as usual. You *could*, yes. But then that's yet another perversion on what USE flags are, and it means that suddenly reinstalling isn't reinstalling any more (what if a user wants to reinstall something, but that it doesn't get reinstalled because the package mangler thinks that you're just altering flags?). Do you really want a user to have to 'reinstall' something twice to reinstall it? -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] RFC: optinal run time dependencies
On 06/28/11 12:38, Peter Volkov wrote: > Hi guys. We've had discussion on optional runtime dependencies in bug > 361255, but I think it's worth to have broader discussion of this issue. > [SNIP] > Comments? I like the USEflag approach. It integrates well with the rest of the machinery. Speaking from experience with "other distros" that have optional dependency support - be really REALLY sure it's an absolutely optional feature that you handle like this. There's nothing worse than spending 15 minutes trying to figure out why stuff is broken, just to realize that the mandatory optional dependencies were not installed. (Yes, mandatory. But optional. Yey!) Since we have useflags anyway I don't really see a strong usecase for making some useflags different - we even have default-on and default-off methods, and if a user doesn't like something it's easy to change locally. But more metadata around the useflags might be very convenient. > May be instead of ~ introduce three additional prefixes (~ and another > two for +~ and -~ cases)? That looks a bit weird :) -- Patrick Lauer http://service.gentooexperimental.org Gentoo Council Member and Evangelist Part of Gentoo Benchmarks, Forensics, PostgreSQL, KDE herds
Re: [gentoo-dev] RFC: optinal run time dependencies
On Tue, 28 Jun 2011 14:38:19 +0400 Peter Volkov wrote: > Starting with EAPI=X new prefix ~ is allowed in IUSE use flag > definition. Use > flags prefixed with ~ are not allowed to be used anywhere but only > inside > PDEPEND dependency specification. This USE flags are used during > dependency > resolution as normal. Package manager is allowed to skip > re-installation of the > package due to this USE flag change but still it should record such > USE change > into package database. How about packages having optional rt dependencies on other packages' optional dependencies? > Comments? > > May be instead of ~ introduce three additional prefixes (~ and another > two for +~ and -~ cases)? I think a USE_EXPAND prefix could be used for that as well. We could then extend the backwards compatibility to cause complete package rebuilds with older PMs (EAPIs) and only dep-switches for newer ones. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] RFC: optinal run time dependencies
On Tue, 28 Jun 2011 12:03:28 +0100 Ciaran McCreesh wrote: > Have you seen how Exherbo solved the same problem? exheres-0 has > 'suggested' and 'recommended' dependencies, which are variations on > post dependencies. Suggested dependencies are displayed (along with a > description explaining what they do for the packages suggesting them) > but not taken by default, and recommended dependencies are taken (but > shown as just being recommended) unless the user says not to. Seems to me like just another configuration file for user to cope with. We can achieve the same results with the special USE Peter suggested and USE defaults, using the same configuration mechanism as usual. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] RFC: optinal run time dependencies
On Tue, 28 Jun 2011 14:38:19 +0400 Peter Volkov wrote: > Hi guys. We've had discussion on optional runtime dependencies in bug > 361255, but I think it's worth to have broader discussion of this > issue. Have you seen how Exherbo solved the same problem? exheres-0 has 'suggested' and 'recommended' dependencies, which are variations on post dependencies. Suggested dependencies are displayed (along with a description explaining what they do for the packages suggesting them) but not taken by default, and recommended dependencies are taken (but shown as just being recommended) unless the user says not to. To avoid annoyance, there are two special cases. First, if a suggested or recommended dependency is already installed, then it's treated like a regular post dependency for upgrades etc (so you don't have to take suggestions every single time). Second, there's a config file allowing users to permanently 'untake' or 'take things. So let's take an oversimplified 'git': DEPENDENCIES=" suggestion: dev-perl/TermReadKey [[ description = [ Dependency for 'git add --interactive' ] ]] ( dev-perl/Authen-SASL dev-perl/Net-SMTP-SSL ) [[ *description = [ Dependency for 'git send-email' ] *group-name = [ git-send-email ] ]] " Here, when a user first tries to install 'git', they get something like this (output abbreviated for clarity): n dev-scm/git:0::arbor 1.7.5.4 to ::installed bash-completion curl -doc -emacs -ipv6 python I did not take the following: (n) dev-perl/TermReadKey:0::arbor 2.30 to ::installed "Change terminal modes, and perform non-blocking reads" Reasons: dev-scm/git (sug): "Dependency for 'git add --interactive'" Take using: --take (n) dev-perl/Authen-SASL:0::arbor 2.15 to ::installed "Perl SASL Authentication framework" Reasons: dev-scm/git (sug): "Dependency for 'git send-email'" Take using: --take (git-send-email) (n) dev-perl/Net-SMTP-SSL:0::arbor 1.01 to ::installed "SSL support for Net::SMTP" Reasons: dev-scm/git (sug): "Dependency for 'git send-email'" Take using: --take (git-send-email) Here, the user can just go ahead and install 'git' if they like -- untaken dependencies are just informational, not an error. Or they can do some of the following: * They can '--take TermReadKey' etc. Or they can use the 'group name', like '--take git-send-email', since suggested dependencies often come in groups and it's handy that way. * Similarly, they can '--take-from git'. There's also '--ignore' and '--ignore-from'. They're not widely used in practice. * They can update the 'suggestions.conf' file to record their choice. But this isn't usually necessary, because of the "if a suggestion is already installed, automatically take it" behaviour. It's mostly used to say "I've seen this suggestion, and don't want it, so don't show it to me again". Still, it's handy for suggestion groups if, say, git send-email's optional extra dependencies keep changing. Seems to work rather well in practice... -- Ciaran McCreesh signature.asc Description: PGP signature
[gentoo-dev] RFC: optinal run time dependencies
Hi guys. We've had discussion on optional runtime dependencies in bug 361255, but I think it's worth to have broader discussion of this issue. = Abstract Optional runtime dependencies are dependent packages that are not required to run program but when installed enhance program run-time features. Below new use flag prefix is suggested to handle such rdeps. Motivation Optional run time dependencies are packages that are not required at runtime but when installed provide additional features for program. For example, app-text/asciidoc works fine without media-gfx/graphviz, but to generate diagrams from a textual specification media-gfx/graphviz have to be installed. Currently there are two common approaches for this problem: 1. add a use flag to control runtime dependency 2. add elog message into pkg_postinst to notify users that some features depend on installing package A, B, etc. Both of this approaches are suboptimal. Use-flags (1) will require user to rebuild package just to install optional runtime dependency. elog messages do not present possible features during emerge --preted. So after reading elog message this requires user to run another emerge just to have all asciidoc features installed. elog-message approach complicates developement. Let's consider case where package foo depends on asciidoc with graph support. Without use flags foo-ver.ebuild have to contain something like: RDEPEND=" app-text/asciidoc media-gfx/graphviz" Now it is possible that graph provider for app-text/asciidoc changes (e.g. on graphviz-ng). In such case all this packages that require asciidoc with graph support will have to be updated (controrary to use-flag approach where asciidoc[graphviz] dependency is sufficient). Also sometimes more then one package is required to provide feature. net-im/psi it requires both net-im/psimedia and app-crypt/qca-ossl:2 for voice calls (jingle) support: PDEPEND=" jingle? ( net-im/psimedia app-crypt/qca-ossl:2 )" net-im/psimedia builds fine without app-crypt/qca-ossl:2 but it is still required to have working jingle in psi. Such dependencies are not very evident for non-maintainer and may cause problems during upgrade if, say, another bar dependency will became required for jingle support, but user/developer will be not very attentive rereading yet another time ewarn messages. Also elog approach adds text into anyway overloaded elog output. Specification Starting with EAPI=X new prefix ~ is allowed in IUSE use flag definition. Use flags prefixed with ~ are not allowed to be used anywhere but only inside PDEPEND dependency specification. This USE flags are used during dependency resolution as normal. Package manager is allowed to skip re-installation of the package due to this USE flag change but still it should record such USE change into package database. Rationale Since use-flag approach has only one drawback it's good idea to fix it. Backwards Compatibility This should be inside some future EAPI thus is backward compatible. Already existing prefixes (+ and -) are allowed to be in any part of prefix, i.e. IUSE="~foo ~+bar +~baz" should work. = Comments? May be instead of ~ introduce three additional prefixes (~ and another two for +~ and -~ cases)? -- Peter.