gnustep-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Changes I've been thinking of...


From: David Chisnall
Subject: Re: Changes I've been thinking of...
Date: Thu, 8 Oct 2009 12:46:47 +0100

On 8 Oct 2009, at 12:22, Richard Frith-Macdonald wrote:

You are right, I did misunderstand ... I understood the term 'packager' to refer to the person/people responsible for providing GNUstep with a distribution ... ie for a set of packages which are all intended to work together as part of an entire system (such as Ubuntu) and where the 'packager' would reasonably be expected to set policy for all users of the system.

On most systems I've looked at, the same person is responsible for maintaining the core GNUstep packages and a number of application / bundle packages.

I think what you are suggesting is probably (usually at least) undesirable ... a person providing a single package of their own piece of software should probably *not* be setting policy for the system and therefore should not be setting global defaults.

Not at all. If a person installs a theme, for example, or something like WildMenus then it is generally understood that they will want to use it. If this person is installing it systemwide, then it is generally understood that they will want to use it for all users. If you install any systemwide GNUstep bundle then the package should enable it by default for all users.

I am not talking about someone installing a bundle in their home directory after compiling from source, I am talking about someone installing a package. Someone wanting to install a GNUstep-based environment will typically just select a metapackage in their package manager and install everything (GNUstep core, bundles, frameworks, and apps) in one blob; they should not then be expected to configure things by hand, and they especially should not be expected to configure things by hand per user.

However, for the scenario you are suggesting the answer is still pretty much the same ... the packager could do it the same way as with most other software ... edit the file using standard unix tools such as sed and awk. Of course, we could provide specific utilities like plmerge, but 'standard' unix techniques of marking sections of the file with comments and removing/inserting stuff between those comments would work just fine.


Adding an entry to a dictionary that may or may not already exist in a plist file is... nontrivial with sed / awk. You will note that other software these days generally does not modify files like this. Instead, they provide a configuration directory. A good example is Apache, where various modules are generally installed as separate packages. In the bad old days, things worked exactly as you describe. Packages modified the configuration file, and if you were lucky installing or removing a module package would not trash your httpd.conf (although good luck if you ever tried to upgrade a module package). Now, each module installs a separate configuration file.

I used the appkit user bundles as an example, but this problem equally applies to any app that supports plugins which might be distributed in separate packages.

David

-- Sent from my brain





reply via email to

[Prev in Thread] Current Thread [Next in Thread]