While it's possible to customise the returned update.rdf using the xpcomabi passed in the url or something I think it would be useful to also just be able to check any targetPlatform in the update.rdf same as we do in install.rdf

This is a really usefull feature.

Dave, please provide an explanation for: What |Removed |Added ---------------------------------------------------------------------------- Target Milestone|mozilla1.9.2 |mozilla1.9.3 Is this 'feature' deemed unimportant? (i.e.: Do you think it will fix itself when we all have x86_64 and i386 is obsolete?)

(In reply to comment #2) > Dave, please provide an explanation for: > What |Removed |Added > ---------------------------------------------------------------------------- > Target Milestone|mozilla1.9.2 |mozilla1.9.3 > > Is this 'feature' deemed unimportant? (i.e.: Do you think it will fix itself > when we all have x86_64 and i386 is obsolete?) It is not deemed urgent enough to warrant working on a fix in the timescale of a 1.9.2 release given that there are possible workarounds and more important issues. This issue may either go away or be simpler to fix with changes expected in 1.9.3. If anyone wants to provide a fix sooner then I will review it and it could be considered for the 1.9.2 branch.

This explanation implies that the update still `feature` does not provide us with the right arch package, i.e. the update feature fails. i.e.: This is a bug, not a feature request.

A little subjective whether this is a bug or an enhancement I guess. It doesn't make any difference. It is possible to serve updates for the correct architecture currently without this (addons.mozilla.org already does) so there is no urgency to fix it.

Per policy at https://wiki.mozilla.org/Bug_Triage/Projects/Bug_Handling/Bug_Husbandry#Inactive_Bugs. If this bug is not an enhancement request or a bug not present in a supported release of Firefox, then it may be reopened.