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

[Richard Frith-Macdonald]

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.