Re: gEDA-dev: Gschem and Cairo graphics library

[Russell Shaw <rjshaw@xxxxxxxxxxxxxxx>]

John Doty wrote:
> On Jul 31, 2006, at 10:13 PM, Russell Shaw wrote:
>
> > John Griessen wrote:
> > > Russell Shaw wrote:
> > >  click Ok to install them.
> > >
> > >> All the right information is there in existing command-line  tools, and
> > >> only a gui frontend is needed.
> >
> > > No,
> > > It's not.  I just hit this lack of complete dependency information  
> > > the other week with debian.  All my problems updating to the  latest 
> > > pcb cvs were due to incomplete or overlapping dependency  info in 
> > > seemingly unrelated debian packages.  Some of the parts of  systems 
> > > like X11 or Xorg were undocumented snags probably since  they were 
> > > self tested, but not against eachother since of  different vintages.
> >
> >
> > The testing and unstable part of debian can have problems like that  for
> > new packages such Xorg.
> >
> > The point is that all the infrastructure is there for complete  
> > dependency resolution and it is only a matter of eliminating packaging bugs.
>
> But each distro has different packages. Serious expert labor is  
> required to maintain the packages. It is very difficult to test that  
> all dependencies are accounted for.

But it is the package maintainer of that distro that worries about
package dependencies.

All the "upstream" author for a package does is make it buildable with
all necessary checks done with autoconf. That's all geda authors need
to worry about. At a minimum, if a user was to manually compile geda
and install it into /usr/local/, autoconf should tell them of any
missing library, rather than just failing during compile.

All the dozens of linux distros have their own maintainers responsible
for packaging. They write the distro-specific packaging specifications and
scripts to pull in all the dependency packages when geda is installed.
Most distro packages are pre-compiled binaries, with some distro packaging
scripts.

So on Debian you should then just: apt-get install geda
and all dependencies will be automatically downloaded and installed too.

> > > Using the static built Klik package may be the best way to promote  
> > > good FOSS tools with recent libraries.  Sure, it has bloat because  
> > > of the static build. The users who want that fast install don't care.
> >
> >
> > It's a typical attitude of windoze users that it's all about "me me  me".
> > Regardless of whether their pc is part of a botnet spamming the  
> > internet,
> > they're still happy.
>
> Remember that for a lot of us the computer isn't a cool toy, but a  way 
> to get real jobs done. Time wasted configuring is money down the  drain.
>
> Consider a large commercial program like Mathematica. An X86/X86-64  
> installation of Mathematica 5.2 needs 640 MB of disk space. This  
> includes things like 45 MB of private libraries and 27 MB of fonts.  
> Bloat? Remember that disk space is down to ~$1/GB. By using things  that 
> a distro *might* provide, Wolfram *might* be able to save 200 MB  or so. 
> That's 20 cents worth of disk space. But what they gain by  this "bloat" 
> is trivial installation on almost any reasonably  configured X86 Linux 
> system. Wolfram lists tested distros, but others  work too (I run it on 
> Gentoo, not listed by Wolfram).
>
> Distro-specific packages are a good thing, and we should honor those  
> who maintain them. But there's also a place for a nearly foolproof  
> hermetic package. That's also an honorable pursuit.

With proper packaging by the distro, you do get a "foolproof package".

If you get dependency problems, you can fix the packaging specs for
your distro, or try another distro.

By making a large static-linked blob, you're just saying you don't trust
*any* distro packaging system.

When a dependency library is upgraded on your system, all the things that
use it get the benefit too. A static blob will be stuck with the old
libraries it came with.

The reason commercial packages have been done as these closed blobs is
because most commercial unices don't have a packaging system with a large
team of maintainers. Closed blobs are a thing of the past from the dark
ages when you even had to purchase the C compiler for your unix for an
extra $17000 or whatever.

The only time a closed blob would make sense now is if you want to install
it onto one of these commercial unices like HPUX or whatever, but the sysadmin
is clueless or nonexistant and the users are doing the install and are also
clueless. Oh, did i mention Windoze has no packaging system other than big
closed binary blobs?

It seems geda is focusing on windoze users to the detriment of all else.

Lastly, the closed static blob is absolutely immune from all changes in the
rest of the system, exchanging automatic upgrades from new system libraries
for absolute stability. Is that worth it, given that upgrades to system libraries
rarely break dependent aplications in most distributions?


_______________________________________________
geda-dev mailing list
geda-dev@xxxxxxxxxxxxxx
http://www.seul.org/cgi-bin/mailman/listinfo/geda-dev