<div class="gmail_quote">On Thu, Dec 16, 2010 at 2:47 PM, Andrew Flegg <span dir="ltr"><<a href="mailto:andrew@bleb.org">andrew@bleb.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
1) A meta-package, as Ville describes, which depends on the two packages.<br>
This might live in 'user/' (TBD) and be called something like<br>
"qt-community-fixes-1". I don't think this should be a general<br>
"community hotfixes", because then it makes no sense for QML apps<br>
to depend on it in general. However, the SSU could depend on it to<br>
pull it in more widely.<br>
<br>
2) A change to Packages which just checks for the appropriate hotfix<br>
packages; i.e. instead of depending on one metapackage, instead<br>
QML projects have to depend on both fix packages.<br>
<br>
Given the problems with HAM & meta-packages in the past, I'd like to<br>
know we were confident in the behaviour if we took option #1.<br>
<br></blockquote><div><br>IMO #2 is a no-go actually (which makes #1 the only way :), as if we allow per-hotfix dependencies, we will have a mix of hotfixes that HAM will never allow to nicely upgrade (if you have fix A as part of the hotfix metapackage, and then with the next iteration a B hotfix comes, HAM will actually refuse to install an app requiring hotfix B because that would require updating A, but that was part of another app -> you get a 'problems' tab). Some PyQt users might find this scenario familiar, so I suggest we actually encourage to serve the fixes in bundles - that would also make testing easier, etc).<br>
</div></div><br>