408156 - Ability to split prefs into multiple files

Status: RESOLVED WONTFIX

(Core :: Preferences: Backend, enhancement)

Description

[Josh Triplett]

User-Agent:       Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.8.1.11) Gecko/20071128 Iceweasel/2.0.0.11 (Debian-2.0.0.11-1)
Build Identifier: 

I keep my home directory in version control, as a means of sharing it across systems, keeping it backed up, and tracking changes to it.  I'd like to add some of my Firefox and Thunderbird configuration to version control as well.  However, prefs.js contains various types of preferences, some of which I want to version and some of which I do not.  For instance, in Firefox, I want to version prefs like dom.disable_window_move_resize, browser.startup.*, and browser.formfill.enable, but I do not want to version prefs like app.update.lastUpdateTime.*, print.*, or extensions.lastAppVersion.

user.js provides one possible solution to this problem.  I could certainly add some prefs to user.js and check that into version control, while leaving prefs.js untracked.  However, this has some major disadvantages: it overrides preferences set through the UI, it forces me to find new preferences for user.js manually, and it does not let me version machine-specific preferences separately.

I would propose a different solution: some way to specify different files for different sets of prefs.  This way, I could have the prefs I want to version written to prefs-global.js, machine-specific prefs written to prefs-local.js (or better yet, prefs-${hostname}.js), prefs I know I don't want to version written to prefs-ignore.js, and all other prefs written to prefs-new.js .  I could then check in prefs-global.js, version the machine-local prefs by checking in all the prefs-${hostname}.js files, ignore prefs-ignore.js, and check prefs-new.js for any new preferences to categorize.

This approach would simplify several use cases:

* Versioning a home directory.
* Otherwise distributing personal settings across many machines.  (For instance, by using synchronization tools such as unison.)
* Sharing preferences between OS partitions on the same machine.  This approach would allow splitting general preferences and OS-specific preferences into separate files, sharing the former, and keeping the latter separate.
* Applying policies to different classes of users, such as via tools like Sabayon.


Reproducible: Always

Comment 1

[Josh Triplett]

One further note: if the idea seems reasonable, I would willingly help implement it.

Comment 2

[zug_treno]

Related to Core bug 147344 and/or Core bug 252640?

Comment 3

[Josh Triplett]

Potentially related, though I wouldn't call this bug a duplicate of either of those.  The framework to solve this bug would solve *part* of each of those bugs.  Both of those bugs could reasonably depend on this one.

Comment 4

[Josh Triplett]

Marking as NEW, since this defines functionality necessary to solve two other bugs which have passed through NEW.

Comment 5

[Josh Triplett]

> Status: NEW → RESOLVED
> Resolution: --- → WONTFIX

A comment would be nice...

Comment 6

[Mike Kaply [:mkaply]]

Actually the easiest way to do what you are trying to do is via autoconfig:

http://mike.kaply.com/2012/03/16/customizing-firefox-autoconfig-files/

You can even most the config files server side.

Comment 7

[Josh Triplett]

(In reply to Michael Kaply (mkaply) from comment #6)
> Actually the easiest way to do what you are trying to do is via autoconfig:
> 
> http://mike.kaply.com/2012/03/16/customizing-firefox-autoconfig-files/
> 
> You can even most the config files server side.

I'd love to use autoconfig, but as far as I can tell it only works at the system level with the default preferences file, rather than via a user's prefs.js or similar.  Does any means exist to trigger the autoconfig mechanism via a file in my profile or elsewhere in my home directory?  If not, then autoconfig doesn't fix this bug.