Re: gEDA-dev: Re: Gschem and Cairo graphics library

[Igor2 <igor2-at-NOSPAMinno_dot_bme_dot_hu>]

On Mon, 31 Jul 2006, Mike Jarabek wrote:

<snip>

> There was some discussion of a chrooted distribution on the list the 
>other day, and this approaches, and goes furhter than indeed,  the model 
>that the `big guys' use.

Well, yeah, this why I try to get people to test it on various distros. I
think it would solve the problem of dependencies for long. Actually I
believe we should have such a chrooted bloatware (currently the test
version is ~200 megs unpacked) which contains everything, a windows
install and a source version. This way the users who are the laziest would
install a windows and use the windows installers, the less lazier ones
could use the chroot tarball on their Linux without knowing _anything_
about libs or installation or dependencies. And finally, the users who are
willing to learn to track what software they have could use a source or
the package manager of their distro without facing the "this thing won't
be in gEDA because it would introduce another dependency" stuff every day.

And yes, who is too lazy to track his software or understand some very
basic thing about his own system, will end up wasting disk space (and
probably other resources), _whatever_ method gEDA developers will choose
at the end. The real question (for me at least) is whether those lazy
users will (indirectly) enforce their need for waste on non-lazy
users. (No offense, but I couldn't find a better word for lazy.)

Actually I am a bit disappointed since I see many users raising their
voice against dependencies and no feedback about my tarball (which would
be not much effort to try, probably 5 minutes + the download which can be
done in the background). Ok, I've placed the stuff online less than 2
hours ago, but still... :)

>    Point c,  most if not all of the commercial tools have a generic 
>wrapper script around each of the tools.  Most have at least the notion 
>that there are multiple binary platforms that can be supported.  That 
>is, most have some kind of 'bin' directory that has one plain text 
>script and many softlinks to that script with the name of the tool.  In 
>the script there is usually an environment variable that is used to 
>point to the top of the release directory tree and that environment 
>variable is used to create additional entries to the user's PATH, and 
>LD_LIBRARY_PATH.  Moreover, the script then constructs the command to 
>actually execute the right binary image, while doing so, it usually 
>includes a test for a particular architecture to pull up the right 'bin' 
>directory.  This is common practice and I have seen it mimicked all over 
>the place.

Yes, we could do that with the chroot as well. However, I'm not sure how
big such a tarball would be... As windows users need a windows installer
and "any Linux distro" is wide enough for the less lazy users, I would
prefer to see 2-4 chroots compiled for different architectures and a small
script or program that the user could run on his Linux. This small program
would determine whether the host system has Linux kernel and is supported
by a tarball, if so, would suggest the user which tarball to download and
maybe optionally it could even try to download it. Of course this test
program should not have dependencies either, so it should be a static
linked elf or maybe a javascript (hah, I rarely run javascript myself!).

>    If we really want to make it easy to install and not get into 
>dependency hell for our users, we have to put together something as 
>described above.  That means foregoing the low bandwidth to download 
>source code alone as a user.  Everything has to ship in giant tarballs 
>or ISO images, we can't get convienience for free.  But we do get "Click 
>Click Click".

I'm in, I just need some real users (I mean those who say they don't want
to use their distribution's package manager) to test the test tarball. It
really isn't worth a dime that I tested it on my own system and it ran...

bye

Igor2



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