Packaging Drush
A couple of weeks ago I was once again manually installing Drush as there were no packages for CentOS / EPEL or whatever, apart from the needed patch to get it running on a 5.1.X RHEL php
I had found this thread on Drupal.org mentioning that a package already exists
however David had not answered the exact location yet
So I created a drush package with a with the above mentionned patch and sent it to Jon Ciesla again he gave some suprising feedback ;)
Drush itself might need to be modified in Fedora. It seems
like one of the major functions of drush is to install and update
modules. That's great for modules we don't ship as rpms, but we can't
allow drush to modify modules that we ship.
This feedback pretty much leaves me with 3 options.
The first one is the easiest one, I just forget about packaging drush for Fedora.
The second one would require me to patch Drush so that for all existing drupal modules that have been packaged for Fedora, Drush will call yum to install them. This obviously would create a lot of work maintaining this excludelist.
The third one would be to disable the download functionality for Drush in a Fedora/Rhel enviornment, Jon suggested that this would probably be the saftest path.
(Jon also suggested a fourth option, namely removing all drupal modules from fedora and add a prohibition to package them in the Packaging Guidelines, which he immediately called ridiculous.)
I once again understand the problem of the Distribution maintainer, but on the other hand if I were the upstream Drush developer I wouldn't want to see my software severely disabled in a distribution.
So what do you folks think, disable the functionality or not ?
PS. Yes I've contacted upstream , but I haven't gotten a reply yet.
Comments
#1 James Avory : I feel that there are many
I feel that there are many useful options. Drush packaged could be nice of course and a pain to patch drush for the second or third options is not that painful. I think that there are maybe only three new options but not everything comes with a revolution. Sometimes slow evolution is also good.
#2 Jon Ciesla : Questions
Hi, tyrannical Fedora maintainer here. :)
I've read the above, and am intrigued.
@Grayside Like a drush plugin to call yum and check if a package exists and if not install the usual way?
@Berdir to paly devil's advocate, the advantage to having Drupal modules in yum ias simply security updates, which for many, means security updates period. I know that Drupal can handle this for you, but there's a horse-to-water problem there. WRT site-specifica installs, those can't be in RPMS, period, so drush could still manage these since it's site-aware.
@Robert Douglass Like a yum plugin to call install via drush? Yum uses RPMS to determine dependencies. Security implications of yum pulling in code from outside it's repos aside, do Drupal modules have a method for programatically declaring which other modules they need? Besides, even if we "cripple" drush, it'll be in the Fedora RPM, which you wouldn't have to use, even on Fedora.
@FGM Exactly, and though while I have, at root, no objection to shipping conflicting software, I suspect that even with warnings in the docs, there'd be those who tried to use both, and I'd get the bug reports. :) Hence my desire to find a solution in software.
@moshe weiztman Install or update operations will just fail on the ones packaged by Fedora, since the files will be owned by root, and Apache runs as the httpd user.
@Matt Farina That's one option, but I still wonder about security updates. Is there a way to call drush from a script to update all modules? I'm thinking of a cron job here. Just speculating. You can already use drush to install drupal and modules on Fedora, just don't use the RPMS in yum.
What's the problem with Drupal 7 and PHP 5.2? Fedora has 5.3 currently.
#3 Kris Buytaert : @jon
"What's the problem with Drupal 7 and PHP 5.2? Fedora has 5.3 currently."
The problem is on RHEL/CentOS/EPEL
#4 Grayside : Just brainstorming on Option
Just brainstorming on Option N+1, could the CVS checkout option be extended to utilize a package manager defined in config?
Another option to try an alternate download method in the event of a non-existing project name would allow failover from yum to cvs.
#5 Berdir : Confused
I don't know the packaging system of Fedory (Only Ubuntu/Debian) but I'm a bit confused.
From what I know, a packaging system like deb or rpm is to install a software once per system. However, a single system can have multple drupal installs (probably even different versions) and each of these installs can have a drupal module/theme installed or not. Or even multiple times, if you have a multi-site install.
Now I'm failing to see how yum/rpm could install a drupal module for a specific site...
The only option *I* can see is that distributions only package/distribute drush which can then be used to install/mainain actual drupal sites.
For example, Ubuntu/Debian does have a Drupal 5/6 package, which is installed into /var/something and available at localhost/drupal and therefore imho pretty much useless.
#6 Robert Douglass : Make yum call drush
But don't cripple Drush.
#7 FGM : Same problem with PECL extensions
The problem is very similar to the one existing with PECL extensions: a few selected extensions are made available by distro maintainers, while others are not and need to use the pecl install process.
From what I've seen (on ubuntu, not fedora, though), there is just no prohibition on pecl installing, say, APC, although the package exists within the apt repository, and trying to use one without uninstalling the other will wreak havoc. It needn't be that much different for Drush: if someone is able and willing to use drush (resp. pecl), he should be able to understand he should avoid using the OS distribution system.
#8 moshe weitzman : silly policy
please don't call it drush if it can't update modules. thats just misleading. IMO, people who don't want their modules updated via drush won't be using the update command.
further, drupal7 ships with the ability to add and update modules from the GUI. will Drupal 7 be banned from Fedora if one module decides to package with Fedora?
#9 Kris Buytaert : thnx
Moshe,
Thnx for my feedback, I kind of had the same idea about it ..
Your point about D7 having that functionality is a nice one.. maybe with that argument in the background I'd try to get the package in :)
PS. Dunnow if you got my message on Drupal.org from a couple of weeks ago ?
#10 moshe weitzman : I don't recall seeing that
I don't recall seeing that
#11 Matt Farina : 4th option
I don't like any of these options. It would be nice to have drush packaged and a pain to patch drush for the second or third options. If these 3 are the only options I would suggest continuing to manually download and install drush.
I kind of like the idea of drush being distributed and used as the method to get to all modules, themes, and profiles. Wouldn't this make for less to maintain in the distribution? Instead of managing drupal along with modules and themes drush is what would need to be maintained. Or, use drush to do the installation of drupal and it's modules.
This problem is going to be compounded when Drupal 7 comes out and requires PHP 5.2.
#12 John Arundel : Drupal and Puppet
I just came across your 'Packaging Drush' post and wanted to add this as a comment there, but comments are closed - perhaps you can move this over there if you want to.
I've taken somewhat the opposite approach to handling Drupal/Drush in CentOS - everything's installed and updated with Drush via Puppet, giving an interface in Puppet much like that for RPM packages. I'd be interested to know what you think:
Puppet Drupal recipes