For userfriendly reasons I suggest one directory with all necessary Files in a zip File.

Advantages:
Easy install, just unzip in a new directory.
Everything is separate from earlyer versions, so testing is easy.

Disadvantages:
?

How to install the third party libraries (e.g. gtk2 or qt)? How to update?
How many zip file flavors must be supported?

Mattias

The installer should do this already. I build my own 2.5.1 binaries and installer once a week from the source snapshots and upgrade my existing install using the installer I've built. My installer installs and updates everything provided the user enters the correct path in the installation program.

The best would be to support the most popular zip file algorithm.

How to update?

To avoid problems make a new directory and then download the whole files needed to write freepascal programs. So if something is not working then still there is an older directory that is ok. In the future updates can be done with a more sophisticated solution. But at the beginning there is a functioning solution.

How to install the third party libraries (e.g. gtk2 or qt)?

I am not familiar exactly with the libraries.
You mean the C Libraries?
Aren't they already there in the Linux distribution?

Can you provide details?

Well, what kind of details? I just use the installer that comes with the source snapshot.

I thought you wrote the installer.

I meant flavors like: Build for i386 or x86_64, for gtk2 or qt, for which Linux distros, for single or multi user, ...

No.

Mattias

Mattias Gaertner wrote

I meant flavors like: Build for i386 or x86_64, for gtk2 or qt, for which Linux distros, for single or multi user, ...

Of course the best would be every possible flavor. Also the best would be that it is compatible to all Linux distros.

I wrote a program which uses X-Window system and I didn't find a distro the software is not compatible with. The best is to minimize dependancies.

So I would prefer to not depend on qt or gtk whatever, but that is another story I think.

But the libraries for X-Window are included I found out.

Mattias _______________________________________________ fpc-pascal maillist - http://lists.freepascal.org/mailman/listinfo/fpc-pascal

No, I just used the one that comes with the source code.

In our previous episode, Rainer Stratmann said:

Not guaranteed. That's what the dependancies are for, working via the package systems "should" bring them in if they are missing.

And the qtintf library is mostly likely not available.

Would it be possible to put all the needed libraries in on ~/fpc_install_xxx directory with all other programs so that lazarus looks there first for the libraries?

Then also no root rights are needed (simple).
An less other dependancies and problems are created (f.e. version conflict).

With the X-libraries in the program directory it works for me on a linux system which has not X-window (voyage embedded linux http://linux.voyage.hk/).

In our previous episode, Rainer Stratmann said:

Not without system reconfiguration so that the system searched for libs there, and getting this fault-free is near impossible.

The only solution is to not do that and link everything that is potentially a risk into one big binary. Commercial vendors.

But they often only support one or two distributions formally.

In general, this IMHO is a dead end. Many have tried, and many have failed. Even if it works, the maintenance effort is even more killing than the current situation, since you are totally on your own.

Also because of the design of lazarus.
Instead of emulating win32 api on every other system it would be better to emulate for example fpGUI on win32.

The only solution is to not do that and link everything that is potentially a risk into one big binary. Commercial vendors.

Also a very good solution would be to not rely on the many different libs.

But they often only support one or two distributions formally.

Solution see above.

In general, this IMHO is a dead end. Many have tried, and many have failed. Even if it works, the maintenance effort is even more killing than the current situation, since you are totally on your own.

No that's not true.
Look at fpGUI and MSEgui.
The programmers of these applications are experts in what they are doing. These are working examples how to come to independency. And also I think the maintenance is very easy since then there are less dependencies to the libs. That means less complications.

FPC has some dependencies too. For example binutils. And to develop you almost always need some more tools and development libraries.

Instead of emulating win32 api on every other system it would be better to emulate for example fpGUI on win32.

Huh? Either my English is not good enough or you have no idea what you are talking about.

> The only solution is to not do that and link everything that is potentially > a risk into one big binary. Commercial vendors. Also a very good solution would be to not rely on the many different libs.

One is enough to get the hassle.
Linux comes in many flavors and FPC and Lazarus support that. And IMO both are good things.

msegui is already split into three debian packages. This is the situation of Lazarus several years ago and of FPC a decade ago. Then package maintainers split the packages into more and more independent chunks.
FPC and Laz supports many third party libraries.
Of course there people who don't care for this, so they ask for the base set of FPC and Laz with minimum requirements. Other users need a third party library. And that's why FPC and Lazarus were split into many packages on Debian.
So actually, what you think is complicated, is the answer to the many different requests.

In the end the solution is always a compromise of time and skills of volunteers.
If you want to volunteer then the FPC and Lazarus team will support you.

Mattias

FPC has some dependencies too. For example binutils. And to develop you almost always need some more tools and development libraries.

Instead of emulating win32 api on every other system it would be better to emulate for example fpGUI on win32.

Huh? Either my English is not good enough or you have no idea what you are talking about.

> The only solution is to not do that and link everything that is potentially > a risk into one big binary. Commercial vendors. Also a very good solution would be to not rely on the many different libs.

One is enough to get the hassle.
Linux comes in many flavors and FPC and Lazarus support that. And IMO both are good things.

msegui is already split into three debian packages. This is the situation of Lazarus several years ago and of FPC a decade ago. Then package maintainers split the packages into more and more independent chunks.
FPC and Laz supports many third party libraries.
Of course there people who don't care for this, so they ask for the base set of FPC and Laz with minimum requirements. Other users need a third party library. And that's why FPC and Lazarus were split into many packages on Debian.
So actually, what you think is complicated, is the answer to the many different requests.

In the end the solution is always a compromise of time and skills of volunteers.
If you want to volunteer then the FPC and Lazarus team will support you.

Mattias

But that is the goal of Lazarus. Provide native look and feel. Native on windows is the win API, and on Linux it is GTK and QT. If you do not want that, then you can switch to msegui and fpgui.

Well Lazarus does support more than only those native ones, but they are an essential part of Lazarus, and removing them, is like replacing Lazarus by another product.
So by the definition, of what Lazarus should be, the dependencies are there, and always will be.

Similar for FPC. For hello world, you may not need much of a dependency. But include for example databases (any DB at the users choice), access to web servers, ...., then your fpx installation will need to pull in those package.

So simple provide a zipped folder with all in it, will not help. Providing a zipped folder with all in it, will leave it to the user, to ensure he somehow gets all the requirements himself => that would make it harder.

I wonder what the exact problem is?

Let's say you had a new system, no Lazarus and no fpc installed yet => does the current installer do a bad job? Then it needs to be improved. The installer should download all Lazarus/fpc (or the parts you selected), and pull in all dependencies. Once finish, you should just run Lazarus, and all does work.
If it does not, then it needs fixing.

Updates should be similar. So long as you have not modified any config files that you were not meant too. Again, if it does not, then the discussion should be, were this fails, and if it could be improved.

If 3rd party add-on package fail, then the question is, if it is a problem in the 3rd party package or in the Lazarus updater? And a single folder does not guarantee that such update issues disappear. In fact it can create new ones (if 3rd party stuff is in the single dir of Lazarus, then it may accidentally be partly deleted....)

If you try to install more than one version, I know there are pitfalls. I don't know how good the installer is. The installer should have options to specify a target director. I GUESS, where this options are depends on your system. At least it should, as anything else would be re-inventing the wheel...
But running several versions in parallel, is not just a question of installation, it requires special setup/config too. And yes in this case the use of "in-folder-config-files" rathe than config in standard locations (which is where they should be) have been discussed. It is good practice to follow those standards. So that is not a Lazarus problem, that is how most (all?) modern operating systems are designed.

Anything else, it would be best to describe a concrete scenario, and point out where the problems are.

Best Regards
Martin