On Tue, 11 Apr 2017 03:29:25 +0700 "Vadim A. Misbakh-Soloviov" <gen...@mva.name> wrote:
> Am I right in assumption that you arguing about *_TARGETS rework to > be enabled by default for packages that was not tested on this > TARGETs with ... hardness of packaging java software?.. I think TARGETS should not exist. They do not for Java, Perl, or PHP. > And yes, some times I even thought "F**k this sh*t!" (but finished > packaging afterwards). You must have been packaging small stuff. Anything big requires tremendous time. Even for simple ebuilds. Short of using an automated tool to generate the ebuilds like the java-ebuilder https://github.com/gentoo/java-ebuilder > And yes, I packaged Go software. I have as well, it sucks, no versions. Rackspace rack command is in go https://github.com/Obsidian-StudiosInc/os-xtoo/tree/master/dev-go https://github.com/Obsidian-StudiosInc/os-xtoo/tree/master/app-admin/rack > And yes, I packaged NodeJS software. > > And no, they are NOT much easy to package then Java one (even > including they still have no TARGETS... As java? :D). I do not just package but maintain. This discussion is in part about ebuild maintenance. As you have to manage PYTHON/RUBY stuff in the ebuild. Not just the TARGETS users see. > But how does it apply to TARGETS logic breakage? If you haven't run into it, then your not aware. Its an update issue. You set a target to say Ruby 24. But something wants Ruby23. It could be it only builds with ruby23. Or more than likely no one has gotten around to adding it to the package. Since for every new version. EVERY ebuild must be touched. That is thousands wrt to Python, and hundreds wrt to Ruby. Even if scripted. Added a new version would take some time to update all ebuilds. Its silly work. > The purpose of TARGETS is that package holds only that TARGETs that > it was tested to work against. I am aware. Java could do things that way. So could Perl and PHP. Why is they do not? For anyone saying go look at Python Ruby. 3 other systems exist, those teams are ignoring. Coming up with a complex, cumbersome solution that the others are not plagued by. > It is wrong to have any targets > enabled by default for all the packages and removing in case if it is > broken. Instead, if new target appeared a month (year, decade) ago, > but package, that you're interested in, still doesn't support it... > Well.. It meant, maintainer is a slacker and package is a candidate > to last-rites and removal... All you should have to do is set the python/ruby versions via eselect. Eclasses and ebuilds should handle the rest as they do for the other 3 main languages. -- William L. Thomson Jr.
pgpf0XP82GGyT.pgp
Description: OpenPGP digital signature
