2

I have made a distribution, which contains some modules which are in dev state. These modules are being by drush make checked out by git. So my drupal-org.make file contains something like:

projects[ctools][type] = module
projects[ctools][download][type] = git
projects[ctools][download][url] = http://git.drupal.org/project/ctools.git
projects[ctools][download][revision] = e720f61
projects[ctools][subdir] = "contrib"

(I need ctools' current dev version because of a batch that was commited shortly after 7.x-1.4 came out.)

This works ok but when using my distro I always get "security updates available"-warnings, which I would not get if I downloaded and used this same dev version on a standalone project.

Ctools update status

What is the best way to handle this? Can I somehow tell drush make to download a specific dev version, as these dev versions are packaged by d.o. and are idenifiable: e.g. version = "7.x-1.4+4-dev"

  • As far as I know you can't really prevent warnings. And I don't think you should - user of your distribution have a right to know if he is using insecure code. On the other hand, using [download][branch] and [version] instead of [download][revision] might get you something closer to the effect of manual installation. Can't test now, feel free to experiment and post self-answer with details filled in if I'm right, I'll be glad to upvote. – Mołot May 13 '14 at 9:12
  • drupal.stackexchange.com/questions/27791/… will get you the desired effect, but I would think long and hard before using it. Hiding insecurities from users of your distribution is a very bad idea. Some might say it's irresponsible. – Clive May 13 '14 at 9:16
  • 1
    @Clive the point is, if he installs by hand, there is no message. Message is there only when he installs by revision ID, as it fools the Drupal's update script. The very same script thinks the very same dev code has no security issues, if installed another way. – Mołot May 13 '14 at 9:32
  • @Mołot So this is a bug report, yes? Or is it documented as the expected behaviour somewhere do you know? (I glossed over that part first time round, good spot) – Clive May 13 '14 at 9:48
  • @Clive Yes and no. Question about writing drupal-org.make in a way that will not trigger this bug seems legit. I hope someone (maybe me, later) will be able to test my guess from my first comment, or provide another solution. On the other hand, bug report should also be posted. – Mołot May 13 '14 at 9:49
3

Article Common Drush Make errors and their solutions has a solution for you. It seems that you should provide both branch and revision, if you want to clone exact revision and still have other info filled properly.

projects[ctools][type] = module
projects[ctools][download][type] = git
projects[ctools][download][revision] = 747151e
projects[ctools][download][branch] = 7.x-1.x

Although you're specifying both a revision and a branch, drush make is smart enough to use the more specific thing (the revision) when cloning. It just uses the branch information for other metadata (updating the .info files in the things it checked out, and for displaying the contents of the distribution on the release node).

Emphasis mine.

  • @drupov I don't want to sound like a beggar, but if this worked and you confirm it does, you could click accept mark under votes. It will give me some rep, true, but only about 0.11% of what I already have... but more important, it will say "this worked for the person who asked" to everyone who will happen to read your question in the future. – Mołot May 20 '14 at 10:54
  • sure, I'm still new to SE. Of course I am accepting! :) – drupov May 21 '14 at 14:53

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.