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

[Eric Heintzmann]

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

> La plume l=E9g=E8re, vers Sun, Jun 13, 2004 at 05:04:18PM +0100, heure=
=20
> d'inspiration,
> Eric Heintzmann =E9crivait en ces mots:
>>> But well, their point of view is nonetheless understandable, it's >a=
lso=20
>>> normal >that they want to reserve general names like terminal or=20
>>> preferences >for >meta-packages. And if they want to rename theses=20=

>>> packages as >backbone-preferences or backbone-terminal, I don't find=
 it=20
>>> shocking, >as >preferences, terminal or textedit are parts of backbo=
ne.
>=20
> 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 wa=
y
> there is now a GNOME and a KDE category.=20

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 releas=
e).

>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.

>=20
>>> A better solution imho would be to add ".app" to GNUstep apps names=20=

>>> >rather >than prefixing with gnustep- .
>>=20
>> Well, this solution doen't satisfy everyone and doesn't solve the nam=
ing=20
>> problem on frameworks (like netclasses) and libs.
>=20
> netclasse.framework_version.deb ?
Already refused (like addresses-framework and addressview-framework).

Eric