[OpendTect_Developers] What is the actual state of the project?

[Júlio Hoffimann]

Hi Bert,

When trying to reproduce the "error" to fix it, i noted that is not a file
permission problem, something wrong is happening and i don't know what. I
read the script generated by Makeself and seems to be ok. Let me explain...

Every downloaded file in Linux has it's execution flag setted to off
(security reasons), so the current installation process is something like
this:

$ chmod  +x unix-devel-opendtect-4.0.1.download (give execution permission)
$ ./unix-devel-opendtect-4.0.1.download (run)

The script unpack the *.tar.gz file and try to run ./inst_gpl_pkgs.od, this
message appears:

eval: 1: ./inst_gpl_pkgs.od: not found

Aparently a simple file permission problem, but the unpacked script is ok
with the execution flag on. I tried to find errors in Makeself script,
looking for wildcards characters expansions inside ' ' instead of " ",
nothing strange. Anyway, i didn't want to install at that moment, for me was
better this error had occured :-).

The INSTALL_NOTES file i told is a simple text file inside *.tar.gz
explaining to the user how to install OpendTect:

==========================================
This is OpendTect, a geocientists software developed by dGB, ...
It's under three different licenses: GNU gPL, ...

How to install:
===========
./inst_gpl_pkgs.od

==========================================

The installation difficulty increase is insignificant and Makeself is not
crucial:

Unpack *.tar.gz
$ ./inst_gpl_pkgs.od

But the better approach in Linux systems is to use distribution's
repositories. You don't need to dispense time creating an installer for
Linux. I don't know how hard is it, but certainly is the better approach to
disseminate OpendTect in such systems.

These videos illustrates what i talking about:

http://www.youtube.com/watch?v=Y8xzFgux-PM
http://www.youtube.com/watch?v=YHBDd0GGWEY

The second one is an old version of the Ubuntu system, but shows how simple
the installation can be.

Every Linux distribution (Ubuntu, Kubuntu, Debian, Red Hat, Fedora, Suse,
...) has it's own "software center", a program capable of download and
install softwares in repositories with one click. There is a rumor that
Microsoft will copy this feature too in Windows 8.

Best regards,
Júlio.


2010/11/4 Bert Bril <bert at opendtect.org>

> Hi all,
>
>
> Júlio said:
>
>
> > I did ask about Makeself because is not so common and because sometimes
> > the researcher/programmer just wants to check the source code of the
> > project to get familiar. An "INSTALL_NOTES" text file is simple and
> > inhibits an unwanted installation. Also, there are file permission
> > problems.
>
> Could you please explain both the above. We have HTML doc explaining a
> lot and I have never encountered permission problems. And 99% of the
> people make plugins.
>
>
> > Anyway, you told about an installer, this certainly nullifies
> > the discussion for the binaries in a user point of view :-). But for me
> > and many other programmers, a *.tar.gz continues to be the better choice
> > for the source code.
>
> The installer will manage download and install of such packages, so
> we'll be continuing to make such packages, and you'll always be able to
> find them on ftp.
>
> We'll switch to zip on all platforms BTW, but zip is available
> cross-platform too so that cannot be a problem.
>
>
> > No, i meant VCS (Version Control System). CVS is a particular VCS and,
> > sadly, an anagram too :-). Today, most of the projects are migrating to
> > distributed VCS's, like Git, Mercury, etc. Some famous are KDE, the
> > recent LibreOffice created as a community manifestation to Oracle
> > impositions under OpenOffice.org office suite. Both, KDE and
> > LibreOffice, are now using Git instead of a centralized VCS (CVS,
> > SVN,...). The main developers has total control of the project when the
> > VCS is configured correctly. This is why disasters don't happens and
> > Open Sources projects can grow.
>
> The thing is that we would welcome the very first usable source
> contribution from an external source. We are Open Source and in
> principle people could contribute, but in practice we don't see anything
> else than development of commercial plugins. The OpendTect base system
> grows thanks to sponsors most notably dGB (delivering all the software)
> and some other companies contributing money and usage/test. BG is by far
> the most important sponsor (others include Statoil, ENI, Gaz de France,
> Marathon, Addax, ...).
>
> We're not the only OS tool in that position, see for example COIN. And
> then, they are *much* more generally usable. But even for them the
> problem is that they are not in the operating systems or generalized
> tools. We make even much more specific stuff for a very specific target
> group (geoscientists in interpretation).
>
> For COIN, we contribute code every now and then, and they basically
> integrate things after re-work to their own standards, if they integrate
> at all. And I can understand that.
>
>
> So my view is: let's first try whether not having Git or similar is a
> real problem. If at some point this becomes a real issue, we can look
> into it.
>
>
> /Bert
>
> --
> -- Bert Bril / OpendTect developer at dGB
> -- mailto:Bert.Bril at opendtect.org , http://opendtect.org
>
>
> _______________________________________________
> Developers mailing list
> Developers at opendtect.org
> http://lists.opendtect.org/mailman/listinfo/developers
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opendtect.org/pipermail/developers/attachments/20101105/f0718e0d/attachment.html>