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: Richard Frith-Macdonald
Subject: Re: Changes I've been thinking of...
Date: Thu, 8 Oct 2009 13:30:01 +0100


On 8 Oct 2009, at 12:46, David Chisnall wrote:

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.

Yes ... that's what I was thinking of.

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.

OK ... we just have different perceptions here then. In those circumstances I expect a package to be *available* to all users, but NOT to be automatically forced on them. Certainly *I* don't want to have something like that imposed on *ME* just because someone else installs a package globally. That's what I mean about 'policy' ... I don't mind policy being set by the person who managed the distribution (I wouldn't be using the distribution if I didn't think its managers policy was a good one), but I would hate to have it set just because someone else sharing the system with me decides to install a package and make it available to me. We can probably agree to differ on this ...it's not really very relevant.

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.


Well I really don't see your problem ... It *is* trivially easy for someone familiar with unix tools (awk in particular) to add entries to a property list using those tools, especially if you (as the package manager) control what's in there anyway. If you don't happen to like doing it that way (I tend to agree with you there, but I gave the sed/awk example as the method most frequently used historically), you can use the mechanism in the example you gave yourself (from apache) and just build the plist by merging plists from the installed packages (in which case you handle uninstall by uninstalling your package and rebuilding the global defaults plist from the remaining installed packages with plmerge).

Either way, my point remains the same ... it's up to the packaging systems used by the distribution how they do things, the task is much the same as with any other software, not a GNUstep specific issue, and it's really not our concern how packagers for different distributions do things. If you are putting together a package for Debian, you ask the Debian maintainers how they want things done rather than asking the developers. We can certainly give advice, but it's not our job to dictate this.





reply via email to

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