1541491 - Evaluate whether we can stop using compatibility.ini in the common case where app compat info is in profiles.ini / installs.ini

Status: NEW

(Toolkit :: Startup and Profile System, defect, P3)

Description

[:Gijs (away/busy until Mar 10)]

It seems like we're using compatibility.ini to check whether the profile is compatible, even after we've used profiles.ini to ensure this.

Can we just remove compatibility.ini, or only read it when we've been explicitly passed a profile directory (instead of nothing, or a profile name from profiles.ini) ?

Comment 1

[Dave Townsend [:mossop]]

We use compatibility.ini to attempt to figure out which profile should be the default on the transition to dedicated profiles. But other than that use the profiles.ini doesn't contain any of the compatibility.ini data that we need on startup in order to decide whether to invalidate the caches. We could add it all to profiles.ini and only use compatibility.ini for non-named profiles I guess.

Comment 2

[Dave Townsend [:mossop]]

I suspect that there is not a lot to be gained here.

Comment 3

[:Gijs (away/busy until Mar 10)]

(In reply to Dave Townsend [:mossop] (he/him) from comment #2)

I suspect that there is not a lot to be gained here.

I'm not sure. The files involved are all so small that the additional file opening is probably worse than moving some of the info, certainly in the common case of one app + one profile. Plus I wonder if we can just remove some of this info... do we really need to list the app dir separately, and do we really need the OSABI stuff? Based on https://bugzilla.mozilla.org/show_bug.cgi?id=326772 it was intended for mac universal builds (RIP) and component re-registration (but we no longer support compiled components in the profile dir, and haven't for Quite A While).

Anyway, old and crusty code so probably more than just a few days' work...