discuss-gnustep
[Top][All Lists]
Advanced

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

Re: [pkg-GNUstep-maintainers] Re: GNUStep namespace pollution in Debian?


From: Eric Heintzmann
Subject: Re: [pkg-GNUstep-maintainers] Re: GNUStep namespace pollution in Debian?
Date: Mon, 14 Jun 2004 17:06:26 +0100

On 2004-06-13 19:18:35 +0200 Wolfgang Sourdeau <Wolfgang@Contre.COM> wrote:

> La plume légère, vers Sun, Jun 13, 2004 at 05:04:18PM +0100, heure 
> d'inspiration,
> Eric Heintzmann écrivait en ces mots:
>>> But well, their point of view is nonetheless understandable, it's >also 
>>> normal >that they want to reserve general names like terminal or 
>>> preferences >for >meta-packages. And if they want to rename theses 
>>> packages as >backbone-preferences or backbone-terminal, I don't find it 
>>> shocking, >as >preferences, terminal or textedit are parts of backbone.
> 
> Personnally, one idea that comes to my mind is to not rename those
> packages but to keep them organized in a GNUstep category, the same way
> there is now a GNOME and a KDE category. 

When you use command line like apt-get, apt-show-version ... , you only see 
package name (not section or descriptions) ,I think this is why they insist to 
rename package.
(And I don't we can have a gnustep section, at least before sarge release).

>Of course it does not solve the
> namespace "pollution" problem, but otoh, if for example the package
> Terminal.app cannot use the name "terminal", why would another package
> be allowed to... so why condemn the use of such names at all.
In fact terminal could be used by virtual packages (For example Terminal.app, 
xterm, kterm could provide terminal virtual package) and /usr/bin/terminal 
could be used by debian alternative.

> 
>>> A better solution imho would be to add ".app" to GNUstep apps names 
>>> >rather >than prefixing with gnustep- .
>> 
>> Well, this solution doen't satisfy everyone and doesn't solve the naming 
>> problem on frameworks (like netclasses) and libs.
> 
> netclasse.framework_version.deb ?
Already refused (like addresses-framework and addressview-framework).

Eric





reply via email to

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