The current version of conky 1.10.8 is currently behind the upstream releases. conky 1.11.0 was released on Dec 2th 2018. When I recognised this 1.11.2 or even 1.11.3 was released. There are currently two reasons this newer versions are not in the tree: First, the new version requires at least lua-5.2 which is masked in Gentoo. For this I already have a working version which works well. Second, for some features conky used toluapp [1]. However the development of toluapp seems to have ceased not supporting recent versions of lua. Thus starting from conky-1.11.2 it bundles a customised version of toluapp [2] so I decided to not add this versions to the tree for now. There is still the possibility to add them without the toluapp functionality. This effectively means removing the lua-cairo, lua-imlib and lua-rsvg use flags. To be able to further use toluapp functionality it should be unbundled from conky, released as a separate project, then packaged for gentoo for conky to be able to depend on it. There is also a version available at Github [3] which claims to support lua-5.2 and 5.3. I wont find the time to do so. I will however try to find the time to ask conky upstream about this issue. Maybe there is a chance to unbundle toluapp again. @Rafael: I put you on CC as the current maintainer of toloapp. @David: I recognised your recent work on toluapp. Maybe both of you have some input to share regarding this situation. [1] https://github.com/LuaDist/toluapp [2] https://github.com/brndnmtthws/conky/tree/master/3rdparty/toluapp [3] https://github.com/waltervn/toluapp
Sorry for my ignorance, but may I ask what's wrong with using bundled toluapp just for conky, why do you need to extract it into separate package?
(In reply to Alex Efros from comment #1) > Sorry for my ignorance, but may I ask what's wrong with using bundled > toluapp just for conky, why do you need to extract it into separate package? Because it is considered ill practise. If every program would bundle each dependency, library, etc, we would end up with multiple copies on the system. They will have different versions and what is most important security issues. So to fix a security issue all of the programs using the affected bundled parts have to be updated instead of only one which all of the programs depend on.
(In reply to Daniel Pielmeier from comment #2) > Because it is considered ill practise. Of course. But it's questionable is this reasoning is critical enough to became a release blocker.
(In reply to Alex Efros from comment #3) > (In reply to Daniel Pielmeier from comment #2) > > Because it is considered ill practise. > > Of course. But it's questionable is this reasoning is critical enough to > became a release blocker. There will be an update but for sure everything related to toluapp will b disabled.
(In reply to Daniel Pielmeier from comment #4) > (In reply to Alex Efros from comment #3) > > (In reply to Daniel Pielmeier from comment #2) > > > Because it is considered ill practise. > > > > Of course. But it's questionable is this reasoning is critical enough to > > became a release blocker. > > There will be an update but for sure everything related to toluapp will b > disabled. as far as i know, bundling patched deps isn't such a big issue, there are occurrences of that in the tree. you can add an use flag that disables the bundled library, removing the functionality that requires it, if you really want to.
(In reply to Rafael Martins from comment #5) > (In reply to Daniel Pielmeier from comment #4) > > (In reply to Alex Efros from comment #3) > > > (In reply to Daniel Pielmeier from comment #2) > > > > Because it is considered ill practise. > > > > > > Of course. But it's questionable is this reasoning is critical enough to > > > became a release blocker. > > > > There will be an update but for sure everything related to toluapp will b > > disabled. > > as far as i know, bundling patched deps isn't such a big issue, there are > occurrences of that in the tree. you can add an use flag that disables the > bundled library, removing the functionality that requires it, if you really > want to. Something being in the tree does not imply it is correct or the proper solution [1]. Nevertheless I went ahead and added a bundled-toluapp USE flag which has to be enabled if lua-cairo, lua-imlib and/or lua-rsvg are requested. It is probably not optimal but this way everybody will be aware of the bundling if one or more of this features are requested. Looking forward to the bugs to come. [1] https://wiki.gentoo.org/wiki/Why_not_bundle_dependencies
(In reply to Daniel Pielmeier from comment #6) > (In reply to Rafael Martins from comment #5) > > (In reply to Daniel Pielmeier from comment #4) > > > (In reply to Alex Efros from comment #3) > > > > (In reply to Daniel Pielmeier from comment #2) > > > > > Because it is considered ill practise. > > > > > > > > Of course. But it's questionable is this reasoning is critical enough to > > > > became a release blocker. > > > > > > There will be an update but for sure everything related to toluapp will b > > > disabled. > > > > as far as i know, bundling patched deps isn't such a big issue, there are > > occurrences of that in the tree. you can add an use flag that disables the > > bundled library, removing the functionality that requires it, if you really > > want to. > > Something being in the tree does not imply it is correct or the proper > solution [1]. I'm not going to share my personal opinion on most of the arguments listed on that wiki page. Anyway, glad to know that you could move forward. cheers :) > Nevertheless I went ahead and added a bundled-toluapp USE flag which has to > be enabled if lua-cairo, lua-imlib and/or lua-rsvg are requested. It is > probably not optimal but this way everybody will be aware of the bundling if > one or more of this features are requested. > > Looking forward to the bugs to come. > > [1] https://wiki.gentoo.org/wiki/Why_not_bundle_dependencies
(In reply to Rafael Martins from comment #7) > > I'm not going to share my personal opinion on most of the arguments listed > on that wiki page. Anyway, glad to know that you could move forward. cheers > :) > Thanks for sharing your thoughts. I am also not agreeing with all of the arguments listed there. Also from a quick grep it seems that toluapp is not massively used apart from conky. It is only two games depending on it. Additionally given that the development of toluapp seems to have stopped while lua continues it probably has to be removed from the tree anyway as it does not work with recent versions of lua. In this case all consumers could benefit from an unbundled version because the one used by conky works with >lua-5.1.
