I'd like to prune old ebuilds to keep the tree clean. following files should be removed. librime-0.9.7.ebuild librime-0.9.8.ebuild files/librime-data-option.patch Reproducible: Always
Are you sure to remove 0.9.8? It seems, that this is the last release, that supports old yaml-cpp-0.3. As yaml-cpp APIs are incompatible, i am not sure when new yaml-cpp will be stabilized and if you have plans to stabilize librime - you will have to wait until it will be stabilized. If you do not have such plans - i will be glad to prune old versions ;-)
(In reply to Sergey Popov from comment #1) > Are you sure to remove 0.9.8? It seems, that this is the last release, that > supports old yaml-cpp-0.3. As yaml-cpp APIs are incompatible, i am not sure > when new yaml-cpp will be stabilized and if you have plans to stabilize > librime - you will have to wait until it will be stabilized. > > If you do not have such plans - i will be glad to prune old versions ;-) the latest release in tree is 0.9.9, and all the versions are keyworded as un-stable. while take yaml-cpp into consideration, I'm not for sure. As I search the whole tree. there are two more package depend on yaml-cpp. media-libs/opencolorio needs specific version =0.3.*(yaml-cpp). another one seems sci-physics/reduze? I think we could still remove 0.9.8 if not take account of other package's dependency. but in the case people already install opencolorio and want to try librime, then they could mask librime-0.9.9, and use 0.9.8, to make them co-exist peacefully. that's the reason I see why should keep 0.9.8. I did't do stabilization work for librime before, are you suggesting doing this? then should we stable all the RDEPEND/DPENDs of this package?
(In reply to Dennis 'dlan' Lan from comment #2) > I did't do stabilization work for librime before, are you suggesting doing > this? then should we stable all the RDEPEND/DPENDs of this package? No, just asking about your plans. If you did not plan to bring package into stable - that's fine. You are maintainer - it is up to you to decide. >I think we could still remove 0.9.8 if not take account of other package's dependency. but in the case people already install opencolorio and want to try librime, then they could mask librime-0.9.9, and use 0.9.8, to make them co-exist peacefully. that's the reason I see why should keep 0.9.8. Yes, that was my point of view as opencolorio maintainer ;-). So, i will drop only 0.9.7 and data-option.patch, ok?
(In reply to Sergey Popov from comment #3) > (In reply to Dennis 'dlan' Lan from comment #2) > > I did't do stabilization work for librime before, are you suggesting doing > > this? then should we stable all the RDEPEND/DPENDs of this package? > > No, just asking about your plans. If you did not plan to bring package into > stable - that's fine. You are maintainer - it is up to you to decide. > We plan to stable librime as I've already talked to @yngwin I've filed a bug about its deps (yaml-cpp-0.5.1, and others) > >I think we could still remove 0.9.8 if not take account of other package's dependency. but in the case people already install opencolorio and want to try librime, then they could mask librime-0.9.9, and use 0.9.8, to make them co-exist peacefully. that's the reason I see why should keep 0.9.8. > > Yes, that was my point of view as opencolorio maintainer ;-). So, i will > drop only 0.9.7 and data-option.patch, ok? Yes, sounds fine. let's keep version 0.9.8. but I'd still like to go to stable librime-0.9.9 (if yaml-cpp-0.5.1 can go stable). and in this case let's just keep version 0.9.8 unstable.
+ 29 Jul 2013; Sergey Popov <pinkbyte@gentoo.org> -librime-0.9.7.ebuild, + -files/librime-data-option.patch: + Drop old files by maintainer's request, wrt bug #478024
