Re: GNUstep and /usr/GNUstep...
Christian Schwarz <schwarz@monet.m.isar.de> wrote:
> Note, that we had a similar discussion with the KDE packages before. KDE
> wanted to install into /opt. After the discussion, the KDE packages have
> been changed by the Debian maintainer (this was surely a lot of work) but
> I think it was worth it: IIRC, the KDE sources have been changed
> _upstream_ to allow installation into the `distributed' directories more
> easily. (Note, that I don't use KDE so this is just what I've been
> told--I hope that it's not completely wrong :)
> [I'm switching to `brain storming' mode now: please don't take all this
> too seriously :-]
>
> So why are all these `desktop environments' designed so that they _need_
> to have everything in a single directory hierarchy? This looks to me as
> they see themselves as `pure add-ons' to other operating systems/
> distributions. Frankly speaking, this looks a bit like the `C:\WINDOWS'
> approach: just add a new directory for your programs and you don't have
> to worry about cooperation with other programs.
>
> In the next step, we'll see GNUstep add-on packages which also need to
> install into C:\WINDOWS^H^H^H^H^H^H^H^H^H/usr/GNUstep. Is this a nice
> solution??
First of all, this is the start of the thread if referred to. My first posting contained a concise description of the directory layout of GNUstep:
http://www.de.debian.org/Lists-Archives/debian-policy-9711/msg00027.html
IMHO, the main problem is that GNUstep has a different POV than the FSSTND. The layout of GNUstep tries to faciliate that developers can ship an application that can be deployed on multiple different target systems (e.g. Linux, Solaris, Win95) in a single app-wrapper directory. E.g. for an application InterfaceModeller
Apps/
InterfaceModeller.app/
InterfaceModeller (for OPENSTEP systems compatibility)
i386/
linux-gnu/
gnu-gnu-gnu-xdps/
InterfaceModeller
win32/
gnu-gnu-gnu-win32/
InterfaceModeller
sparc/
solaris-2.5.1/
nx-pdo-gnu-xdps/
InterfaceModeller
where InterfaceModeller is the binary. Resources common for all platforms (e.g. NIB files that contain the GUI description) would be kept in a separate directory inside InterfaceModeller.app/.
Libraries (aka Frameworks) have a similar layout.
The main strength of this concept is that cross-platform issues are really transparent to the developer and user. In principle, a very heterogenous set of machines could still share one single common directory tree, and installation and removal of packages and libraries is always a task of installing or removing a single directory. This is a situation that FSSTND doesn't get explicit about.
The second point is (Vincent already pointed this out) that GNUstep is an implementation of the OpenStep specification. All other implementations (OpenStep for Solaris, OPENSTEP, OPENSTEP for Win32 and Rhapsody) share a similar directory structure. In fact GNUstep is a cross-plattform development and user environment, and to be generally useful it has to follow some constraints set by the specification.
> Perhaps we can find a `temporary compromise' then: Since a) the packages
> would have to go into `contrib' first (unless the new dgs is released)
> and b) you said `you're not sure if they are really useful', why don't
> you just release them to contrib and install everything into /usr/GNUstep
> for a first release?
>
> Note that by policy, packages in contrib are allowed to be `a bit
> different' :)
>
> With this solution, more people would be able to test your GNUstep
> packages and we'd know `if the packages are useful at all,' while you
> could try to work together with the upstream maintainers to make GNUstep
> installable into `FSSTND' directories (which would be necessary to allow
> the packages to go into the main distribution afterwards).
With the above in mind, converting GNUstep to FSSTND would result in stripping off the cross-platform features, for deployment as well as for development. I doubt the upstream developers would adopt this layout. In fact, until mid 97 GNUstep followed a traditional Unix layout, and it was since then that they came up with the new scheme.
Therefore I agree that putting the packages with the current GNUstep layout into contrib seems most reasonable.
Gregor
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
debian-devel-request@lists.debian.org .
Trouble? e-mail to templin@bucknell.edu .
Reply to: