Currently we have 6.5.0 in portage but drush.org has 7.1.0 as stable. Can we have a version bump please? Reproducible: Always
The 6.x series is the last that we will be able to support. The 7.x and 8.x versions force you to install them via Composer. The upstream "release" tarballs are all broken. I personally think that's pretty stupid, but unless enough people complain upstream, we're out of luck. I did however spot a new 6.6.0 release which I've just added to the tree: https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=abb38536f664542e115936a188d11cc935be7532 *** This bug has been marked as a duplicate of bug 540552 ***
Thanks allot for you effort. I haven't tried those 7.x and 8.x since i prefer to install stuff with portage. This is also the reason i haven't looked into composer. I haven't used pear either (why should i, there is portage). Its sad to see Drush going and i can't believe how stupid this is!
I just digged deeper into this composer stuff some more and even if dislike composer as much as you do, i figured that it wouldn't be impossible to install drush with portage + composer. If you see composer just as another tool to download software (like ebuilds using git instead of curl / wget), you could download a specific version and its dependencies with composer and put it back where it was with version 6. There is an example one line command on Drush install instructions: COMPOSER_HOME=/opt/drush COMPOSER_BIN_DIR=/usr/local/bin COMPOSER_VENDOR_DIR=/opt/drush/7 composer require drush/drush:7.1.0 Having composer as a dependency on drush would be like having webkit-gtk forcing people to install ruby stuff when you only need it on compile time. I know this just a bad compromise but as an administrator with developers demanding newer Drush versions i don't wanna loose support for Drush in Portage. I also tried to convince them with no luck. They say every PHP software will be shipped with composer in future (i somewhat doubt that phpmyadmin will do such things). They seem not even having read the introduction page on composer website. There is a clear statement that composer will not replace existing package management systems of linux and its meant to be used on a project basis. Is there any chance to not loose support of drush in gentoo?
Oh, there is probably a misleading part: I meant downloading with composer into sandbox and putting files into system with portage then.
I understand the frustration... There are two major problems preventing portage/composer integration. The first is that ebuilds are not allowed to have network access. There is even an option, FEATURES=network-sandbox that "disables" your network. And that option will probably become default at some point in the future. As a result, we can't just depend on composer, and then use composer to build/install everything: composer needs network access. The second problem is that composer bundles all of the dependencies for a given package along with that package. That can easily blow up to hundreds of packages "copy/pasted" into yours, since it also fetches dependencies of dependencies, and dependencies of those dependencies of dependencies... That's not strictly forbidden by Gentoo, but it's strongly discouraged. It's also a big weakness in terms of security, especially for PHP projects that often sit on the public internet. If there's a security hole in one of Drush's dependencies, you'd never know it. (Drush isn't public-facing, but you get the idea.) To make everything work, you would have to install Drush locally using Composer, and figure out exactly what it needs for its dependencies. Then you'd have to modify the Composer autoload magic script to look in the normal system location for those dependencies, and remove the ones that Composer has bundled. Finally, you'd have to create a tarball snapshot of the installation on your local machine and use that as the SRC_URI for the ebuild. And you'd have to do that for every new version. It's too much trouble if it's even possible... the composer-installed copy may not like being moved around, and that would cause even more headaches. I tried to do it a few months ago and gave up.
Thanks, i see. While i was complaining about broken download files, requesting working builds and being rejected, it seems like they are building a Phar version Drush. Since i've never been into Phar, i just read a bit about it and it seems like static builds of php software. https://github.com/drush-ops/drush/commit/201273a0d6207ba0e333cbc893fa824bb7b21e1e Do you think it might be possible to use the Drush Phar instead, once it gets available?
(In reply to zasire from comment #6) > Thanks, i see. > > While i was complaining about broken download files, requesting working > builds and being rejected, it seems like they are building a Phar version > Drush. Since i've never been into Phar, i just read a bit about it and it > seems like static builds of php software. > > https://github.com/drush-ops/drush/commit/ > 201273a0d6207ba0e333cbc893fa824bb7b21e1e > > Do you think it might be possible to use the Drush Phar instead, once it > gets available? That would eliminate the network access problem but not the bundled dependencies. However, it may be easy at that point to unbundle the dependencies. I'll certainly give it a try!
Thanks allot!
