distribution packaging plugin doesn't record package contents [#1178942]

When you package an install profile on d.o, it's supposed to include a table of the projects included inside the distro.

I seem to have broken this via #1024942: Add ctools plugin system for site-specific logic for packaging release nodes.

However, now that these two are finally resolved:

#951978: "Unable to determine project type for drupal" when creating release
#751242: Install profiles cannot create releases with a non drupal-org makefile

I'm finally seeing this bug. For example, compare these two:

http://drupal.org/node/1016124
http://drupal.org/node/1048898

Basically, the info about what's included isn't getting propagated and recorded properly. Probably a trivial bug somewhere, since I never had a chance to fully test all this code in the heat of the Git migration.

Comments

Comment #1

dww

we/he/they

commented 4 June 2011 at 23:38

Project:	Drupal.org customizations	» Project
Version:	6.x-3.x-dev	» 6.x-1.x-dev
Component:	Code	» Packages
Assigned:	Unassigned	» dww
Status:	Active	» Fixed

Yup, trivial bug:

http://drupal.org/commitlog/commit/122/f214f3762197762b5508c126054656923...

Tested, committed, pushed, merged into bzr, deployed, and verified working:

http://drupal.org/node/1177666 (although you can't see that until Gabor publishes it since he marked it as a security update).

Not sure it's possible to automatically repair the existing distros that are missing this data. :( We could run some queries to figure out how many are affected and contemplate manually repairing. Not sure that'll be worth it. Although if it's only a tiny handful, maybe it is...

Comment #2

dww

we/he/they

commented 4 June 2011 at 23:44

Ugh, hard to compose a query to find all the releases that are affected by this bug, since there's no obvious way via SQL to tell the difference between the case we care about and the hundreds of releases of install profiles that aren't trying to do a packaged distro at all. :( I think I'll just punt. Over time the current releases will be repaired...

Comment #3

damien tournoud commented 5 June 2011 at 15:46

Status:

Fixed

» Active

mysql> SELECT DISTINCT nid FROM project_release_file prf LEFT JOIN files f ON f.fid = prf.fid WHERE filename LIKE '%no-core.tar.gz' AND nid NOT IN (SELECT DISTINCT package_nid FROM project_package_local_release_item);
+---------+
| nid     |
+---------+
| 1046468 | 
| 1046514 | 
| 1048830 | 
| 1048884 | 
| 1048898 | 
| 1048910 | 
| 1051074 | 
| 1056828 | 
| 1065466 | 
| 1069818 | 
| 1069874 | 
| 1069894 | 
+---------+
12 rows in set (1.06 sec)

Now what?

Comment #4

dww

we/he/they

commented 5 June 2011 at 16:52

Heh, I guess that works. ;) I almost started exploring something like that but I had already written this off as not worth the effort. But thanks. Nice to know it's only 12 distribution releases affected.

re now what: if we want to repair these we could either:

A) manually inspect each one, look at the drupal-org.make file, find versions of core and all included contribs, look up release nids for each one so you get a set of included nids for each distro nid, and insert those into {project_package_local_release_item}.

B) delete the existing packaged files on disk for all these, clear out {files} and {project_release_file} for them, unpublish the 12 release nodes, and have the packaging script rebuild them all. The md5 hashes will all change (due to timestamps in .info files changing) and of course the file timestamps (and perhaps size, too) -- not sure how much we care about that. but it'd be less work than (A), that's for sure.