Re: Flattened GNUstep structure? No!

[Pascal J. Bourguignon]

Nicola Pero <nicola@brainstorm.co.uk> wrote:
> I'm only very slightly in favour of the flattened structure.

I don't  see any advantage to  the flattened structure,  given that it
will be hidden to the end users anyway (by GWorkspace.app), and...
 
> The main argument in favour of the deep directory structure seems to be
> that it can be used to build multi-platforms executables.

(For  example, rpm  has provision  for  building from  source rpms  to
different  architectures,  that  is,  it  is  compatible  with  a  cvs
distribution with deep directory structure.)


> But - since we are going to distribute packages using rpms and debs, my
> question is - does this deep directory structure means we can build a
> single rpm for different linux distributions ?  As far as I understand,
> the answer is `no', because different linux distributions will have their
> binaries all in the same dir ix86/gnu-linux/gnu-gnu-gnu-xgps (except ppc
> which will have a different one) while I assume the binaries should be
> different - possibly for differences in system libraries and so forth ?  

Not a  point against  deep directory structure,  but on  the contrary,
showing that it should be deepened,  or at least, we should add sub os
tags     such    as     gnu-linux-redhat-6.1,    gnu-linux-redhat-7.0,
gnu-linux-mandrake-7.0, gnu-linux-debian-potatoe...


> hhm - I don't know enough to answer - is it because the binaries are
> different that people have different rpms for different distributions I
> suppose ?  If it is not for this reason, then if we use our own same
> layout inside /usr/GNUstep on all machines, we could perhaps make
> different rpms for the core libraries, but then a single rpm <for
> applications which interface to the system only using the core libraries>
> for every linux distribution (with the same characteristics, such as same
> major version of libc) would be enough ?

We cannot  say much  for (third party)  applications because  they may
depend on a  range of other libraries beside  libc. More over, GNUstep
applications will be distributed  as GNUstep Installer packages. We're
only discussing the distribution of the GNUstep system itself.


It seems that while rpm  support multi architecture source rpms, there
can be only  one architecture in a binary rpm (at  least in version 3,
I've not checked later versions).

Therefore, the following practice:

% cd /nfs/common
% wget ftp://ftp.gnustep.org/pub/dist/bins/rpms/i586/gnustep-1.0-rh61.i586.rpm
% rpm -i --prefix=/nfs/common/gnustep gnustep-1.0-rh61.i586.rpm
% wget ftp://ftp.gnustep.org/pub/dist/bins/rpms/sparc/gnustep-1.0-rh61.sparc.rpm
% rpm -i --prefix=/nfs/common/gnustep --ignorearch gnustep-1.0-rh61.sparc.rpm

would  break if  the rpm  installed a  flattened  directory structure (-),
while it would be ok if it installed a deep directory structure (+).

While the following practice:
% cd /gnustep
% wget ftp://ftp.gnustep.org/pub/dist/bins/rpms/i586/gnustep-1.0-rh61.i586.rpm
% rpm -i --prefix=/gnustep gnustep-1.0-rh61.i586.rpm

would be ok both with  flattened directory structure (+) and with deep
directory structure (+).

In addition,  GWorkspace will  anyway show the  same view  whether the
flattened directory structure (+)  or the deep directory structure (+)
is used.

Total: 2 for flattened directory structure
       3 for deep directory structure.

And if we added sub-os/version types to the 'gnu-linux' node, we could
even support  a range  of different distributions,  if that  is really
needed (if they're really that different).


> In any case, it seems to me that the deep directory structure does not
> work for (or against) generating rpms which can run on multiple linux
> intel distributions.
> 
> Certainly, debs have to be distributed separately simply because they are
> debs and not rpms.
> 
> A binary package for windows can not anyway be distributed as an rpm, so
> windows binary distributions have to be shipped again as separate
> packages.
> 
> The other reason to have deep directory structure is to have multiple
> backends on the same machine.  I think this is quite useful but it is an
> advanced feature - core developers will want to do that, but they will
> have everything installed from cvs anyway, and adding an option to
> configure should not be a problem for them.

Not only core  developers, but also any administrator  at a user site,
and this  includes also  single users (well,  application programmers)
that may have several heterogenous  systems. May be I'm special, but I
can have  and use up to seven  computers, of which at  least three, of
different architectures, ran NeXTSTEP, and will run GNUstep.

> In general, I don't see deep structure as a big advantage, while it's a
> bit clumsy to work with for the beginner, so, if we are trying to make our
> system very simple to install and start with to make it available to a
> wider audience, I'm slightly in favour of not making it the default.

Having it is not a big advantage. 
Not having it is a big disadvantage.

For the beginner, it won't  make a difference anyway since it's hidden
by GWorkspace.app.

The same for Display Postscript and  -NXHost... Oh no!  It's not a big
advantage -NXHost... So small an advantage that suits at Apple stashed
it away.




Therefore  I  would  say   (and  this  concerns  only  GNUstep  system
distributions):

   - generate binary  rpms, debian packages, whatever* to install with
     the deep directory structure.
   
   - distribute  a  script  to  flatten  any  GNUstep  deep  directory
     structure, for  those (advanced) users  who don't like  what they
     see in the xterm window.


(*) Even  if the  range has reduced,  I understand  that MS-Windows-NT
 also runs  on a range of  different architectures. Who are  we to say
 that  no  MS-Windows-NT  administrator  may  install  a  shared  deep
 directory  structure for his  GNUstep system  and applications  to be
 used on both MS-Windows-NT-i586 and MS-Windows-NT-alpha, or whatever.

-- 
__Pascal Bourguignon__    PGP Key ID:      0xEF5E9966                     (o_
mailto:pjb@imaginet.fr    PGP fingerprint: 00 F5 7B DB CA 51 8A AD 04 5B  //\
http://informatimago.free.fr/index         6C DE 32 60 16 8E EF 5E 99 66  V_/

() Join the ASCII ribbon campaign against html email and Microsoft attachments.
/\ Software patents are endangering the computer industry all around the world.
   Join the LPF:     http://lpf.ai.mit.edu/      http://petition.eurolinux.org/