Re: [GnomeMeeting-list] Re: Why all the #%$@*(*& dependencies Was: GnomeMeeting-list Digest, Vol 20, Issue 35



Lol...was just a suggestion, should of said I'm no shell
scripter....seems like it would be a good idea though IMO with all
these dependencies people are complaining about...

On 12/19/05, Damien Sandras <dsandras seconix com> wrote:
> Feel free to provide it :-)
>
>
> Le lundi 19 décembre 2005 à 10:18 -0800, Hex Star a écrit :
> > Or perhaps they could consider having you download a install.sh file,
> > and when run it would first check to see if you meet the dependencies
> > and if not it would download and install the dependencies for you from
> > your distros download location and then it would download and install
> > the latest version of GnomeMeeting...
> >
> > On 12/19/05, Jouni Lohikoski iki fi <jlohikos cc hut fi> wrote:
> > > On Sun, Dec 18, 2005 at 11:55:21PM -0500, gnomemeeting-list-request gnome org wrote:
> > > Content-Description: GnomeMeeting-list Digest, Vol 20, Issue 35
> > > > From: Allan <amau sympatico ca>
> > > > Subject: [GnomeMeeting-list] Why all the #%$ *(*& dependencies
> > > > I can understand why it was useful at one time to have all these libraries.
> > > > Storage was expensive, etc.  But now, storage is dirt cheap.  So can someone
> > > > give me a rational explanation as to why developers simply don't include
> > > > everything needed in the packages they produce?  For example, if I recall
> > > > correctly, Opera comes in two flavours - statically linked and dynamically
> > > > linked.  The statically linked package is somewhat larger, but so what?
> > >
> > > In a multitasking environment it makes sense to have as much code as
> > > possible to be shared between other applications. Just think if every
> > > GNOME program would be statically linked and you would be (not even
> > > knowinig) a heavy GNOME user. You would easily need gigabytes of RAM memory
> > > just in a normal office or home computer, or otherwise the system would swap
> > > intolerably much often.
> > >
> > > But I do agree the dynamic linking strategies should somehow be done
> > > somehow alot easier. It is not a big problem to use some good
> > > distribution and install packages and dependencies from that same
> > > distribution, but compiling some CVS code with all the dependencies is
> > > a huge task sometimes. One of the best examples is to compile MPlayer
> > > with all its features from the CVS version.
> > >
> > > Ofcourse developers could make it make more sense, if for example they
> > > would use RPM source packages to distribute also developer and experimental
> > > versions and would always also keep the source library dependencies
> > > updated. But very very seldom I see correct use of "BuildRequires:"
> > > fields in any RPM spec file. In a long run I think it would save even
> > > time when done routinely. But it would require that also library and
> > > other upstream developers would be as conscientious. Also some
> > > Freedesktop Project or Linux Standard Base should "enforce" more
> > > strictly how packages should be named between different distributions.
> > >
> > > < http://www.fedora.us/docs/rpm-packaging-guidelines.html#buildrequires >
> > >
> > > // jouni
> > >
> > > _______________________________________________
> > > GnomeMeeting-list mailing list
> > > GnomeMeeting-list gnome org
> > > http://mail.gnome.org/mailman/listinfo/gnomemeeting-list
> > >
> > _______________________________________________
> > GnomeMeeting-list mailing list
> > GnomeMeeting-list gnome org
> > http://mail.gnome.org/mailman/listinfo/gnomemeeting-list
> --
>  _      Damien Sandras
> (o-
> //\     GnomeMeeting: http://www.gnomemeeting.org/
> v_/_    FOSDEM 2006 : http://www.fosdem.org
>         SIP Phone   : sip:dsandras gnomemeeting net
>                       sip:600000 gnomemeeting net
>
> _______________________________________________
> GnomeMeeting-list mailing list
> GnomeMeeting-list gnome org
> http://mail.gnome.org/mailman/listinfo/gnomemeeting-list
>



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