Top-level directory in packaged install profiles should use the shortname of the install profile project

Does the name of the created directory make any difference?

Subscribe.

I've started to manage my deployments via Aegir, and as #2, have found that downloads of installation profiles have overwritten over downloads.

Is this by design? It is not a good user experience!

Install profile packaging lives in contributions/modules/drupalorg/drupalorg_project/plugins/release_packager/DrupalorgProjectPackageReleaseDistro.class.php

Knock yourselves out. ;)

OK I'll give this a go.

Can I confirm which branch I should patch from? It sounds like 2.x is currently running, but this will switch to 3.x next week with the git migration - therefore, best to patch 3.x - is that correct?

@juliangb: It actually doesn't matter -- I'm pretty sure the file you care about didn't change between the two branches. But sure, if you want to try it with 6.x-3.x that's probably wise. I doubt we're going to deploy this change before the Git launch...

Patch attached.

Caveat that this is the first time I've looked at the release packager, and also have no way to test it myself!

Does anyone have a minute to look at this?

Sorry, this completely fell off my radar. However, I remembered it while working on #1455614: Packaging script doesn't allow distributions to patch core or specify a git revision last night. The patch no longer applies, but it is indeed a trivial fix if/when we decide this is a good idea to change this. Should wait for 1455614 to actually land, but then I can easily get this fixed. It'd just be nice to get more feedback on if it's actually the right thing to be doing. ;)

dww: makes sense, I think
dww: that'd match what modules do

If I understand this correctly (the variable names in the patch aren't very intuitive) then:

The proposal is to change the packaging for install profiles, so that contained top-level directory is no longer

./drupal-x.y/...

but instead:

./[install-profile-project-shortname]-[version]/...

Correct, that's the proposal. Yeah, sorry the variable names are wonky.

It's not really clear whether the proposal also foresees to include the release version in the top-level folder name.

I'm not 100% sure whether it would make sense to include the version, as the most common and wanted operation is most likely to overwrite an existing extracted archive; i.e., an older version.

Likewise, when extracting a module, there's also no version suffix.

EDIT: but as long as the Drupal core tarball has a version suffix, it prolly makes sense to do it for install profiles, too...

Yes, the idea is that if you unpack a tarball called something like:

openpublic-7.x-1.0-beta5-core.tar.gz

You end up with a directory called

openpublic-7.x-1.0-beta5

The point of this issue is to prevent clobbering things by mistake. Therefore, clobbering should be opt-in. Therefore, the directory should include the version.

Note that both of the "no-core" variants do *not* include the version, since that's for the use-case of "upgrading" your site, etc. That's more like a standard module release. This issue is just about the fully-packaged thing, including core.

Re-rolled. Tested on http://distro-drupal.redesign.devdrupal.org. Working great. Any final objections?

Thanks!

Nope -- other than perhaps informing drush maintainers about this naming change to make sure that drush dl picks it up properly.

#1476994: Handle change in top-level directory name in fully-packaged distribution tarballs

I'll give them a little while to respond before I deploy this.

Thanks,
-Derek

drush doesn't care. Committed, pushed, and deployed.

Yay!
-Derek