Hi,

Our company projects requires a flexible and easy to use setup program to work on various Linux distros as well as Windows. Mac support will probably come in a year or two, because currently our applications are only available on Linux and Windows, so that is the platforms we are focusing on.

Anyway, I would like to know what features your guys (as developers) would like to see in a setup program. Most of the features listed below are already implemented or at least went through the brain storming and design idea phase. Here is our requirements and ideas we came up with:

* Linux distro independent setup. Against the normal methods, we do not want to waist time creating .rpm, .deb, .tgz, .tbz etc setups for the thousands of Linux distros out there. Adobe Reader, Jave SDK and JRE are just a few applications that don't follow the package management systems of each distro.

* We want a single file setup, similar to how Windows applications get deployed (eg: a single setup.exe). This makes it easier for dowloading, but we also want the option of an already expanded setup for CD/DVD deployment (no need to expand setup to temporary directory first).

* The setup must be able to run as a GUI if a GUI (X11 under *nix systems) is available, but also be installable if no X11 exists. eg: SSH to a server and install the app via the console.

* The setup must be have a single setup.xml
file that controls the setup.

* Applications must have an Uninstall option.

* Scriptable installs for extra customization. We are trying to keep the basic install executables (setup engine) standard so developers don't need to rebuild the setup engine itself, only need to create archives, setup.xml and package in into a single executable. For this we support pre- and post- install and pre- and post- uninstall scripts. We also support one script per feature (user selectable options of what must be installed). Usage of scripts are optional of course.

* Automatic icon creation on desktop and Application/Start menu.

* Suggested installation paths. eg: /opt/<app>, /usr/local/<app>, ~/<app>, ~/.local/<app>, etc...

* Notification if admin/root security is required

* Selectable features to be installed. eg: Base Install, Help, Extra drivers, etc...

* Notification of hard drive space available and how much will be used by selected features.

* different internal archive options: gzip, lzma, zip, tar.gz etc...

* Even though the setup is a single file setup, it must support native executables. That includes various architectures: 32 or 64 bit, linux, *bsd or windows exectubles etc. Once "full" setup must support all of the above. We are considering making a split between *nix type OSes and Windows OSes though. After all, this is how it is currently done for Linux, Mac and Windows, so end-users are used to that idea.

We are primarily targeting deployment of Free Pascal based applications, but the setup engine should be flexible enough to handle any type of application (we hope). :)
We will probably release the setup and setup builder as Open Source software once done. I hope to create sample setups of Lazarus or FPC itself to show how it can be done.

So what feature do you require in a setup that we did not think of? What's your wish list?

Regards,
- Graeme -

This might prove difficult. on linux, only .tar.gz is guaranteed to be supported. If you want any of the others, you'll have to deploy the uncompression engine as well.

? Most products I know come in separate 32/64 bit installers.

The ones you mentioned only exist as 32-bit installers, which is why they have only 1 setup.

Michael.

My wish list - port innosetup (http://www.jrsoftware.org/isinfo.php) which is written in delphi and is opensource project. We are using it for lazarus windows installs.

Best regards,
Paul Ishenin.

Do don't plan on relying on what libraries are installed in the OS. Such archive options will be natively support via Object Pascal code and built into the setup engine. We already have gzip support and working on lzma support.

? Most products I know come in separate 32/64 bit installers.

True, but we are not limited to that, but separating such installs will make the setup building easy.

How we do it. Lets take *nix application deployment via CD-ROM as an example. Our initial setup.sh is a standard script that should run on any *nix OS. The CD-ROM has rockridge extensions enabled, so executable flag is already set for the setup.sh script. The script detects the architecture and if X11 is available. It then calls the appropriate setup.gui or setup.console executable. The latter executable is the actual installation, the setup.sh is just a "bootstap" script to get things started.

Obviously the setup.sh script is not required if you split your installation in 32/64-bit or GUI/non-GUI setup directories.

Regards,
- Graeme -

Graeme Geldenhuys wrote

So what feature do you require in a setup that we did not think of? What's your wish list?

What I also forgot to mention are a few more features.

* Splash/Banner/Logo image support. If no image is available, the setup GUI window adjust itself accordingly.

* Viewing of README.txt files.

* Viewing and accepting of license agreement is also supported (even though I hate license agreements - and who actually reads those <wink>).

Regards,
- Graeme -

Paul Ishenin wrote

My wish list - port innosetup (http://www.jrsoftware.org/isinfo.php) which is written in delphi and is opensource project. We are using it for lazarus windows installs.

I know about inno setup, but never used it before. We didn't want to port something because we wanted to think out-of-the-box and build it from the ground up with cross-platform support in mind. Trying to make innosetup fit into a *nix environment might just be as much effort as writing a setup from scratch.

Also innosetup is Delphi based, so that is totally limited to Windows platfroms only. When starting from scratch we already use cross-platform features of FPC's RTL, so no need to try and work around the many Windows API calls or Delphi specific features etc.. Porting is not always the fastest way to get a app out.

But I must add, reading through the Key Features of inno setup, I already found a few more ideas I would like to add to our setup wishlist.

Oh by the way, localization support is definitely a given in our setup.

Regards,
- Graeme -

Graeme Geldenhuys wrote

Anyway, I would like to know what features your guys (as developers) would like to see in a setup program.

I can think of the one additional feature:

* Checking dependencies. There is no such problem in fpGUI apps since the only dependency is X :) But Lazarus apps can be stuck to specific GTK/QT version(s). I can remember posts about the GTK API change that made some Lazarus applications crash. Then, there is a plenty of other external libraries our applications can use. I can imagine this as a "missing dependencies" message that is shown if some required library was not found. This seems to be quite difficult though, given the requirement of Linux distro independency...

* Automatic icon creation on desktop and Application/Start menu.

And this seems not so easy too..

Paul Ishenin wrote

My wish list - port innosetup (http://www.jrsoftware.org/isinfo.php) which is written in delphi and is opensource project. We are using it for lazarus windows installs.

This could help very much in the adoption of new install system. Though I think old school Linux users would hate it anyway (according to my observations), it would be good for newcomers if the setup configuration files/scripts look like one of the exisiting install system, such as InnoSetup/NSIS/whatever. In this case InnoSetup has the advantage of PascalScript, that makes it easier to port. So the above suggesion can form one more feature request:

* Familiar syntax of configuration files/scripts.

Vladimir Zhirov wrote

* Checking dependencies. There is no such problem in fpGUI apps since the only dependency is X :) But Lazarus apps can be stuck to specific GTK/QT version(s).

That is exactly why the setup program is written with fpGUI. So even tiny "lite" linux distros or even embedded devices can run the setup. I took the same Linux executable running on Ubuntu 8.04 and ran it no problem on a "tiny" linux distro with just bare X11 installed, and on very old distros like SuSE 9.1 or RedHat 8.0 - all without problems.

Alternatively, the console version of the setup could be used. But my major goal was to use a GUI install whenever a GUI is available. I hate console installs, when I am sitting in a running Gnome or KDE desktop. I want to double click, then click next, next and finish - and be done with it. :)

change that made some Lazarus applications crash. Then, there is a plenty of other external libraries our applications can use. I can imagine this as a "missing dependencies" message that is shown

Currently this could be checked for in the pre-install script and stop the install, or maybe disable certain install features if dependencies are not 100% met. eg: hunspell library is missing so "spellcheck (dictionaries)" install feature will be disabled.

We are looking at some ideas for dependency resolution methods too (*nix OSes mostly). Maybe download or at least prompt the user where to get the missing files, or tap into rpm and apt-get to download those for us. Not 100% sure yet. But this is also why we opt to support Free Pascal base applications as a starting point - they tend to have less dependencies than standard *nix (C/C++/Python/etc.) apps. But obviously we don't want to limit ourselves, so some dependency checks need to be supported.

As for the usage of scripts like the pre-install script... We are setting up various template script functions for all supported OSes, so developers don't have to be expert script junkies to use the scripts feature.

> * Automatic icon creation on desktop and Application/Start menu. And this seems not so easy too..

You wouldn't believe! :-) I have spent the last two days working on this and think I finally found a solution that works 99.9% of the time. Just getting nested menu items to work under Linux was a huge pain (in contrast, Windows was so easy).
eg:
Applications
+-- My Company <-- this being the difficult part +-- My Project
| + My executable
| + Help
| + Uninstall
|
+-- My Second project
+ My executable
+ Uninstall

This could help very much in the adoption of new install system. Though I think old school Linux users would hate it anyway (according to my observations), it would be good for newcomers if the setup

The clients we are targeting are all newcomers to Linux. They are used to Windows with simply double clicking a setup.exe file. This is our goal for Linux to - no opening of command prompts and typing (unless you are an expert or are doing a remote install via SSH).

InnoSetup has the advantage of PascalScript, that makes it easier

I have heard of PascalScript, but have no idea what it really is or how it works. Does FPC support it? I'll have to investigate this further, as it might be a nice cross-platform single source script solution.

* Familiar syntax of configuration files/scripts.

Please explain?

Regards,
- Graeme -

If you want to script your install in InnoSetup, you use pascal. A definite advantage for all Delphi/FPC people.

Michael.

Michael Van Canneyt wrote

If you want to script your install in InnoSetup, you use pascal. A definite advantage for all Delphi/FPC people.

This is the first part of explanation. And the second part is the suggestion to take as much as possible from configuration and script file syntax of some existing open source installation system. This way users would not have to learn new system from the scratch and could reuse their knowledge. There is no need to maintain full compartibility, just to take most important ideas. The good example of this approach is fpGUI itself - it is not compatible with LCL/VCL but it is easy for LCL users to understand the meaning of fields and methods because they have familiar naming. I would like it very much if migration between InnoSetup and new installation system were as easy as migration between LCL and fpGUI. And PascalScript could help to make it so.

Sorry, I got my mails messed up, so here is the missing part:

Graeme Geldenhuys wrote

I want to double click, then click next, next and finish - and be done with it. :)

Well, then one more feature request :)

* Automated install procedure. It could be a command line option to take a text/xml/ini file with setup options and do not require user to press any buttons or type filesystem paths.

I have heard of PascalScript, but have no idea what it really is or how it works. Does FPC support it? I'll have to investigate this further, as it might be a nice cross-platform single source script solution.

According to PascalScript website, FPC is supported. http://www.remobjects.com/ps.aspx
PascalScript is also free and opensource.

Vladimir Zhirov wrote

* Automated install procedure. It could be a command line option to take a text/xml/ini file with setup options and do not require user to press any buttons or type filesystem paths.

Yes we are considering the usual /silent or --silent parameter option, and a option in setup.xml to show but disable (read-only) all user setup options.

PascalScript is also free and opensource.

I didn't know that. I'll take a ,
- Graeme -

* Viewing of README.txt files. * Viewing and accepting of license agreement is also supported (even though I hate license agreements - and who actually reads those <wink>).

Support for user languages and countries.

DoDi

Graeme,

I am sorry to tell you but your project is doomed to failure with the requirements you listed.
In the end you will have a system that "almost works", or works in 85% of the cases, and you will be frustrated yourself.

Your idea is not new. Other people have banged their heads to wall as well. The variation of distros' package formats and directory structures is a bad thing of course, but not as bad as it first looks...

You wouldn't need to build thousands of packages though. The same RPM package works for most RPM based distros (but not all), a DEP package works for Debian based distros. Package managers have sophisticated dependency checks, developed over years. They install needed libs automatically or prevent the whole installation. They have GUIs.
With only few packages you would have a long list of supported distros and then not support some exotic ones.

About Adobe Reader and Java installers: they can't count on any dependencies but must include everything. We also can't know how much their different OS versions differ and how much work has been done to create them.

We are primarily targeting deployment of Free Pascal based applications, but the setup engine should be flexible enough to handle any type of application (we hope). :)

"any type of application" for any OS means endless variation. I suggest you limit the goal to Free Pascal based applications only. There is enough challenge with that. Then, how to handle dependencies? You could make the system to be distro independent by installing from source code, like Gentoo Linux does. Gentoo is complicated because it actually takes care of "any type of application". You system would only know where to find sources for Pascal libs, download them and build using an embedded FPC compiler. Ok, still you need to check the existence of some fundamental system libs but there is a bigger chance for success.
That way it would work for any OS and distro, including the exotic and minimal ones.

Regards,
Juha Manninen

Hans-Peter Diettrich wrote

Support for user languages and countries.

That comes standard with all fpGUI applications. Currently we have translations for 8 languages (af, de, en, es, fr, it, pt, ru).

Regards,
- Graeme -

I'd recommend to use the same syntax as inno-setup. Although developed on Windows the syntax seems fine and it should be possible to extend it where neccessary. Some of the advantages

* fully documented

* you can use the inno-setup editor (as long as you don't have one)

* people are used to it

bye,

Stefan

Juha Manninen wrote

I am sorry to tell you but your project is doomed to failure with the requirements you listed.

With that attitude, ALL developers would be out of business and we wouldn't have things like Linux, OpenOffice or any open source projects for that matter. :-) I gather your thought process is as follows: We only need ONE accounting packages. We only need ONE operating system. We only need ONE programming language. We only need ONE office suite. Yet with all these examples and millions more like it, we have thousands of similar applications.

Our company develops software to fulfil our needs - that's our first priority because we are writing the software. As a courtesy to others we will in all likelihood release the software as a Open Source project. I simply thought that while writing the software, I might as well incorporate some "wish-list" ideas from other developers we haven't thought of. If you don't want to use the software, then don't - nobody is forcing you!

Your idea is not new. Other people have banged their heads to wall as well. The variation of distros' package formats and directory structures is a bad thing of course, but not as bad as it first looks...

We are following some guidelines as proposed by Microsoft, Linux Standards Base, FreeDesktop.org etc. So we do use "desktop standards" and use known locations, file formats etc. This especially applies to Linux.

To give you a Linux example:
* we use xdg scripts when available
* we use recommended *.desktop and *.directory files for menu items
* we use accepted install locations: /opt, /usr/local/, ~/.local/ etc.

You wouldn't need to build thousands of packages though. The same RPM package works for most RPM based distros (but not all), a DEP package works for Debian based distros. Package managers have sophisticated dependency checks,

Does RPM support dependency checks? Last time I used RedHat (years ago) it did not. This is also why we say we support "Free Pascal based" applications more than others. Such applications (in our case, with fpGUI, this is true) have a much smaller dependency. We are definitely *not* trying to compete or replace RPM, DEB, TGZ, TXZ etc... We are targeting the new "desktop users" that know how to use a mouse and click things.

With only few packages you would have a long list of supported distros and then not support some exotic ones.

We don't want to spend three weeks building and packages releases. So we want one installation build process that works for all our supported platforms.

About Adobe Reader and Java installers: they can't count on any dependencies but must include everything.

Yup, we do the same. That's why we use fpGUI and why we use FPC. Both have cross platform support in mind and implement those directly in the resulting executables. Built-in archive support, built-in xml handling ability, built-in database support, built-in file handling, built-in Unicode support, built-in (custom written) help file support and the list goes on... Hence the reason it is easier to deploy our software than C/C++ (thinking *nix here) or .NET or Mono or Java applications.

Regards,
- Graeme -

I'd recommend to use the same syntax as inno-setup.

By that you mean the *.iss file?
eg: <lazarus>/tools/install/win/lazarus.iss

* fully documented

:-) Our setup.xml is already full documented (yeah, programmers that document. WTF??) and the elements used are pretty self describing.

* you can use the inno-setup editor (as long as you don't have one)

There are lots of XML editor too. But with FPC's support for XML, it should be a half-day job writing a setup editor for the setup.xml file. So this is not really an issue.

* people are used to it

XML is a pretty popular standard, so hopefully they are used to xml files too. ;-)

But I get want you mean. I'll take a file (which looks like a standard INI file), but I quite like the idea of using xml files. Just like Lazarus uses xml files for all it's settings. XML is pretty much self describing, and you can create DTD's for them etc.

Regards,
- Graeme -

Graeme Geldenhuys wrote

Does RPM support dependency checks? Last time I used RedHat (years ago) it did not.

RPM surely always did support dependency checks. Some packages have different names across distributions, which ruins the possibility of one package for all RPM if you depend on it, but usually it works just fine with one package for all RPM-based.

Hi!

* we use recommended *.desktop and *.directory files for menu items

Do you mean there is a standard way for that for all window managers? Ok then, I didn't know. There are tens of different window managers around.

Does RPM support dependency checks? Last time I used RedHat (years ago) it did not.

It must have been MANY years ago. I think RPM format has always supported dependencies but the tools didn't support it well in the past. Now the support is very good, as good or even better than in Debian based systems. As a side note, years ago I used Memphis, a Debian based distro. Always when I updated its X11 packages the system broke somehow and I couldn't start X any more. I didn't know how to fix it and had to reinstall the whole system.
Then I switched to RPM based system and never had such problem again. So, superiority of DEP packages is partly a myth.

Ok, I understand. That makes it easier.

Good luck with your project! You have apparently made research about its requirements.

Regards,
Juha Manninen

Juha Manninen wrote

> * we use recommended *.desktop and *.directory files for menu items Do you mean there is a standard way for that for all window managers? Ok then, I didn't know. There are tens of different window managers around.

Yes, there is a standard. Most (still active in development) like Gnome, KDE, XFCE and many other smaller ones support the recommendations from freedesktop.org. So slowly but surely things are improving on the Linux side for software developers. :)

RPM definitely didn't have auto dependency resolution in the last RedHat I used, which was 8.0 or 8.1 I think. So yes, that was very long ago. :) I still remember what a nightmare that was, trying to figure out what do download from where. Same applied to Slackware with it's .tgz files.

So when I switched to Ubuntu in 2005, .deb files and it's repository system was a godsend!

Now the support is very good, as good or even better than in Debian based

That is good to know. Maybe I should try a new RedHat (or is it called Fedora now) distro in a Virtualbox session to see how things changed.

Regards,
- Graeme -

Felipe Monteiro de Carvalho wrote

RPM surely always did support dependency checks. Some packages have

Not in the days I used RedHat. I'm talking long ago, from Redhat 5.0 to about 8.1. :-)

I've just been spoilt with Ubuntu. I guess it's time I start trying out other distros again. Slackware used to be my all time favourite and the first distro I ever tried, plus I installed it over a network at that time. I didn't have a CD-ROM drive or enough working 5.25" diskettes. :-)

Regards,
- Graeme -

Graeme Geldenhuys wrote

Not in the days I used RedHat. I'm talking long ago, from Redhat 5.0 to about 8.1. :-)

Maybe you used it in the wrong way.

The "rpm" utility doesn't solve the dependencies, it's like the "dpkg" utility from Debian.

So you don't use that, but you use another utility that solves the dependencies and calls rpm to do the install work. Just like you don't want to use dpkg directly in Ubuntu.

In Mandriva you do like this: urpmi mypackage.rpm (it also has a GUI)

In Red Hat it should be some similar utility, I think "apt-get". In Ubuntu it is Synaptic maybe? Don't remember exactly the name ...

There seems to be a misunderstanding.
Both deb and rpm have package dependency resolution, but neither downloads them automatically.
You must use tools like apt-get for debs and yum for rpms or even better: use the GUIs. They work pretty much the same. Both can ravage your system (although it is seldom the fault of the package system, but of some packages). Just take a look at the upgrade notes of the various distributions.

> Now the support is very good, as good or even better than in Debian based That is good to know. Maybe I should try a new RedHat (or is it called Fedora now) distro in a Virtualbox session to see how things changed.

Mattias

Exactly.

> * fully documented :-) Our setup.xml is already full documented (yeah, programmers that document. WTF??) and the elements used are pretty self describing.

OK, I thought you are still in the early stages of evaluation.

Concerning XML:

From my point of view XML has it's advantages but is often used where

other alternatives are easier and/or better. I prefer ini-files when it comes to configuration-files and in the case of Inno-setup with it's scripting language I'm really glad that they use ini-files.

regards,

Stefan

It is editable in the text editor. But also by IS-Tool, which is more like an IDE for inno setup scripts.

Vincent

To bad, the ideal setup creator would get a setup.xml and compile it to .rpm, .deb, windows installer, .dmg with Mac OS X package, etc.

Kind of like the Lazarus idea, one source for many OS/widget set combinations.

In setup lingo: many OS/package combinations.

But from the maintainer of fpgui which doesn't use an existing, familiar to the user widget set, another way (one kind of installer that runs on all systems, but does not match an existing packaging system) does not surprise me :-)

Vincent

One can only hope that fpGUI is never ported to OS X or to the burgeoning category of touch-oriented mobile devices.

Thanks.

-Phil

Please stop this flamewar, nobody is forced to use Graemes code.

His only intention was to get some feedback and tell us about his ideas, thats how OSS works.

bye,

Stefan

+ 1

Keep going Graeme !

Luiz

(it might be wise to check out in how far these named programs are shared linked)

* The setup must be have a single setup.xml file that controls the setup.

(Doesn't this violate single file?)

* Automatic icon creation on desktop and Application/Start menu.

Do you plan to support windowmaker? A lot of packages do this wrong under Windowmaker.

Autoinstall of CHM help.

You wouldn't believe! :-) I have spent the last two days working on this and think I finally found a solution that works 99.9% of the time. Just getting nested menu items to work under Linux was a huge pain (in contrast, Windows was so easy).

The is no frame work under Windows for the menu, just files thats why you have silly company's listing there program under there name. The first time I used Linux I loved the clean easy to use menu in gnome the windows menu is one big mess.

You are thinking windows!
Do not put your company name or uninstaller in the Applications menu. No one gives a damn about your company name if someone wants to know who made the program the is a about box for that. E.g, if your first program was a game but your 2nd program was a graphics program then it's better to each program under the right category. Hand over the source and let the Linux distro do their job!

Windows does not equal Linux. Think Windows for Windows, Think Linux for Linux or you will upset alot of people.

Obviously the setup.sh script is not required if you split your installation in 32/64-bit or GUI/non-GUI setup directories.

The only useful thing I can add to thread is check uname -m in your setup.sh then start the right installer. I'm sure you know but sh is not always bash. Mixing up bash with sh is good way to upset 10% of your users.

Ah, so the RPM guys were simply slow on the update of automatic download tools. I heard about yum, but thought it was some new "exotic" package management system. As for apt-get, I thought that was part of deb support. Either way, now I understand apt-get and yum better - or rather how they fit into the whole structure. Thanks.

Felipe Monteiro de Carvalho wrote

Maybe you used it in the wrong way. The "rpm" utility doesn't solve the dependencies, it's like the "dpkg" utility from Debian.

Thanks. Mattias explained that I had a misunderstanding of how things work. External tools do the download for the package management systems. The latter simply does the install/uninstall of packages.

In Red Hat it should be some similar utility, I think "apt-get". In Ubuntu it is Synaptic maybe? Don't remember exactly the name ...

Ubuntu used 'apt-get' for the command line and 'synaptic' as a GUI. Ubuntu being Debian based, it uses *.deb packages.

Red Hat I believe still uses *.rpm packages. 'yum' being the command line download utility.

OK, I thought you are still in the early stages of evaluation.

No, we have had the "setup tool" on the table for some time, we just did have time to implement everything yet. That's my task now.

Actually, I can't agree more. I'm a big fan of INI files and they are very easy to use, thanks to Delphi and FPC. XML files are many times over-hyped and yes, it often gets used in inappropriate situations.

In this case (for the setup tool), we map the features to be installed and there dependencies in the XML as nested elements. eg:
* FPC (base install)
* SqlDB (basic database support)
+ Interbase/Firebird support
+ Oracle support
+ IBM DB/2 support

In such a case "Interbase/Firebird" database support cannot be installed without the "SqlDB" support. So we map that relationship in the setup.xml as well.

Here is a simplified xml layout showing that:

<option id="fpc">FPC (base install)</option>
<option id="sqldb">SqlDB (basic database support)
<option id="firebird">Interbase/Firebird support</option> <option id="oracle">Oracle support</option>
<option id="db2">IBM DB/2 support</option>
</option>

Using INI files it isn't as obvious how to map such a relationship - unless you can give me some ideas. I'm always eager to hear how others would have approached the same problem.

NOTE:
The above xml example is a simplified one. I left out many extra attributes of the <option> element as well as other nested elements inside the <option> element. The <option> element contains other elements like <help>, <script>, <files> etc..

Vincent Snijders wrote

It is editable in the text editor. But also by IS-Tool, which is more like an IDE for inno setup scripts.

I took a second look at the lazarus.iss file to see how "install features/options" and there relationships are mapped in the INI file.

They seem to use one line with various options flattened out in that line that needs to be parsed. This is quite hard to read and follow (using a plain text editor). Like I said, I am not a big fan of XML, but in this case, I think XML would have been a better choice for Inno Setup, but maybe Delphi didn't have built-in XML support like FPC has now, hence the reason they used a INI file. As far as I understand, Inno Setup has been around for quite some time (probably around Delphi 4 or 5)

See my previous reply as to why I think, in the case of a setup configuration file, that XML is a better (and more easy to read and understand with a plain text editor) format.

Good point, but I see a few problems.

1) Using the various packaging formats, those packages would have to be built on dedicated platforms. With the custom install and our supported platforms, I will be able to build setups from inside my one Linux system, using native FPC or a FPC cross-compiler.

2) The other point might be that now you have to learn all the various package management systems out there so you can build the various packages. That will be a huge task (I think).

3) Using the package systems like dpkg or rpm, you cannot do the following:
* show a company logo or other branding
* view a readme file before the install
* select certain features to install (with help on each feature)
* have a one file install (a feature we would love on Linux)
* have other customization options during the install. Not easily at least. I have seen a handful of .deb packages that prompt for a Yes/No question, but that's about it. Most prompted in a console window (ugly) and one or two prompted in a GTK2 dialog (no idea how).

Either way, you raised an interesting idea. Maybe an option for some other Lazarus user to implement. :-)

But from the maintainer of fpgui which doesn't use an existing...

<...snip...>

That's not nice. :-(
BTW: There is another GUI toolkit which does exactly what I am doing with fpGUI, and it is called FOX Toolkit [http://www.fox-toolkit.org] and is implemented in C++. Ever heard of them? They are quite popular, have been around for many years, commercial companies love them, they have a huge user base, little dependencies, lightning fast executables, etc.

So fpGUI isn't that much off the mark by not following the GTK2, Qt etc route. :) I program to fulfill a need and make my life easier in the end. Currently LCL doesn't fulfill my needs, but luckily Lazarus IDE does. ;-)

Please stop this flamewar, nobody is forced to use Graemes code.

Thanks Stefan. I always take what Vincent says with a pinch of salt. We have some understanding that everything goes except on Fridays, and I think I saw a smiley face somewhere between this comments. :)

What Vincent doesn't realize is that fpGUI doesn't have that a unfamiliar interface - I modeled it after Win98, Win2000 and WinXP (classic look). Those were and still are very popular systems. ;-)

True.

2) The other point might be that now you have to learn all the various package management systems out there so you can build the various packages. That will be a huge task (I think).

Yes.
Although for simple programs there are simple scripts and tutorials.

3) Using the package systems like dpkg or rpm, you cannot do the following: * show a company logo or other branding

Not wanted.

* view a readme file before the install

That is possible. See sun java sdk for an example.

* select certain features to install (with help on each feature)

That is possible. See postfix.

* have a one file install (a feature we would love on Linux)

Well, *if* you have internet the deb/rpm package managers are 0 file installers. Just select the package name and click install. Otherwise: Nice feature

* have other customization options during the install. Not easily at least. I have seen a handful of .deb packages that prompt for a Yes/No question, but that's about it. Most prompted in a console window (ugly) and one or two prompted in a GTK2 dialog (no idea how).

The frontend can be anything. Some GUIs shows graphical dialogs for the questions.

Other points:
deb/rpm/ports/... repositories have some advantages:
- mirrors
- databases of all installed files
- databases of all available files and packages
- automatic update of all packages
- automatic install of sets of packages

Mattias

Marco van de Voort wrote

(it might be wise to check out in how far these named programs are shared linked)

True, those mentioned (and ones like ATI and Nvida drivers) tend to be more on the commercial side of things. But then again, our company products are commercial products. :)

> * The setup must be have a single setup.xml > file that controls the setup. (Doesn't this violate single file?)

No, not from the end-users point of view. After creating the setup, one further step is taken using the tool 'makeself'. The setup files (setup binaries, data, setup.xml etc) are packaged with makeself into a single self-extracting file. This is the file that the end-user will download and run. Makeself also has the feature that once unpacked, it can run a command - in our case it will fire off the executable of the "real" unpacked setup files. Once the command makeself executed is done, it even cleans up after itself by removing the unpacked temporary files.

Think of it as a tarball that unpacks and runs itself. Importantly, saving the user from having to do it manually, and sticking to the "one file" deployment. Obviously if the product is deployed on a CD or DVD, the 'makeself' step is not required (and doesn't require a temp location on the hard drive).

For Windows it works similar (but not with the Makeself tool obviously).

Do you plan to support windowmaker? A lot of packages do this wrong under Windowmaker.

If Window Maker supports the LSB or freedesktop.org standards it should work. A quick search on Wikipedia says the last stable release was in 2005, so it might not support the latest desktop standards. I'll make a note and double check for you.

Autoinstall of CHM help.

:-)

Jonathan wrote

The is no frame work under Windows for the menu, just files thats why you have silly company's listing there program under there name.

I haven't looked at that code in a while, but our old Delphi programs created there own icons. I can't remember if it was registry entries or Windows API's. I think we used the latter (but that's me trying to remember 6 years back when I wrote that tool).

The first time I used Linux I loved the clean easy to use menu in gnome the windows menu is one big mess.

I can't agree more. The "category" idea under Linux is so much better than the Windows layout.

I know, it probably was a terrible example, but that is all it was, an example. The idea of nested menu items is what I tried to implement, and even under Linux with the menu "categories" style, nesting menu items more than one level deep is handy.

Here is one example of nested menus under my Ubuntu system.

Applications
...
Programming
+ Lazarus IDE
+ MSEide
+ FPC Documentation
+ Language Reference Guide (pdf)
+ ... (more pdf items here)
+ fpGUI UI Designer
+ DocView
+ LHelp

:-) That is exactly what we do... Here is a snippet of our script

-----------[ setup.sh ]----------------
#!/bin/sh
#
# Bootstrap setup script

# Go to the proper setup directory (if not already there) cd `dirname $0`

# Return the appropriate architecture string
DetectARCH()
{
status=1
case `uname -m` in
i?86) echo "x86"

			status=0;;
		*)     echo "`uname -m`"
			status=0;;
	esac
	return $status

}

# Detect the Unix/Linux environment
arch=`DetectARCH`
....
---------------[ end ]-----------------

s/did have/did not have/ ??

The iss is not that important, a tool like IS-tool is, but without loosing the settings in a text format. IIRC Mac OS X pbuilder has a binary format, which is why I chose to use IceBerg as installer builder for Mac OS X.

In 2000 I would have chosen INI too.

Then the feature is:
A tool like IS-Tool, that is a graphical front end for the settings file in text format, in which all settings can be set, scripts can be edited, the package can be build *and* installed.

Vincent

Point is, are all package management systems equal in there features. Does all of them support showing readme, custom questions, GUI dialogs etc?

And more points against repositories...

* repositories are not meant for commercial software. At least I haven't seen any. And no the "meta" packages that simply install a script, that then has to use something like wget to download the actual commercial software doesn't cut it for us. eg: Microsoft Core Web Fonts .deb package.

* You must have an internet connection (and a reasonably fast one at that). Realisticly, many South African internet user still use dial-up modems.

* A full install of our flagship product is 8GB in size. I don't even want to download that with my 3G modem. My internet connection at home is capped at 500MB per month. Only this year are we switched to DVDs - before that we shipped our product on a CD set (+- 12 disks).

Regards,
- Graeme -

Marco van de Voort wrote

Do you plan to support windowmaker? A lot of packages do this wrong under Windowmaker.

Just because WMaker is not freedesktop compliant ? ;)

z.

zeljko wrote

Just because WMaker is not freedesktop compliant ? ;)

And judging by the progress in recent years, a dead product.

Regards,
- Graeme -

waldo kitty wrote

s/did have/did not have/ ??

Correct. :-) I was typing while being half asleep.

Regards,
- Graeme -

Yes, it is hard, I was just dreaming about what I would like: instead of maintaining inno setups, deb packages build scripts, rpm specs and IceBerg files for Mac OS X, just maintaining one setup solution for all platforms, without sacrificing the user experiences and giving the users a familiar solution: windows installers on windows, deb packages on debian based distros, etc.

I admit, that is true.

2) The other point might be that now you have to learn all the various package management systems out there so you can build the various packages. That will be a huge task (I think).

It is. It didn't stop me from dreaming ...

Yes, that is a familiar trade off. Some features are not supported for all package system (widget set). Other features you get with the package system (e.g. dependency checking and automated downloading on dependencies, when installing).

It was not the intention to say something that is not nice. But why is it not nice? I just noticed the way you treat platform independant widget sets is similar to the way you treat platform independant installers. You are consistent in you design principles. Or I am missing something?

Vincent

Vincent Snijders wrote

way you treat platform independant installers. You are consistent in you design principles. Or I am missing something?

:-) Nothing serious, you are correct regarding my principles. I'm not trying to be different with everything I do. I just have a similar dreams to you. You dream you had a single setup.xml and tool that could create various install packages. I dream of having one tool for my software needs. I have other dreams too though: A nice big LED TV, a PS3, a lawnmower that mows the lawn without my intervention etc. :-)

Regards,
- Graeme -

Just a note, how you can improve your English:

To find out whether to use "there" or "their", try to replace it by "my" and "here". Depending on what fits better, substitute "my" --> "their"
"here" --> "there"

HTH
DoDi

I don't know all systems.

That's why there are linux distributions on dvd.

Graeme, a single file installer is a great idea, so I beg you to implement it.

And when you achieved the goal that your installer has all the information about file destinations, icons, menu entries, registry, ..., there will be feature requests to create deb/rpm from that information.

Mattias

Graeme Geldenhuys wrote

zeljko wrote: > > Just because WMaker is not freedesktop compliant ? ;)

And?

And judging by the progress in recent years, a dead product.

We mostly have it on servers yes. But I don't see why the installer wouldn't be used to deploy a serverside product, with some GUI component as config app.

Still, I wouldn't only support kde/gnome.

The point that I was trying to make, is that they are cross-distro exactly because of that (being mostly statically linked).

That's the crucial difference between Linux and windows in that regard.

Clear. But if it is internal and not user adaptable, all communication must happen (be possible) via the cmdline.

Make it at least pluggable, so that if you need to support some odd ball desktop, you can at least run a script or binary to install the link.

It is less important that it will be perfect, but more a way to avoid that that one user that has a deviant opinion or desktop makes your life hell.

(and you can't whine about freedesktop.org to the customer then, it doesn't matter to him)

Marco van de Voort wrote

The point that I was trying to make, is that they are cross-distro exactly because of that (being mostly statically linked).

OK. In our case, all our products and required features (encryption, xml support, etc) are all compiled into the executable. So we simply need a bare bones GUI to run in.

Clear. But if it is internal and not user adaptable, all communication must happen (be possible) via the cmdline.

It is, yes. makeself can accept parameters to itself or pass them on to the program it's going to execute. Alternatively, you can package the setup in such a way that it doesn't need user interaction.

Make it at least pluggable, so that if you need to support some odd ball desktop, you can at least run a script or binary to install the link.

Each option (feature to be installed) can support a custom script. We also have global pre and post install and uninstall scripts. So you can hook into any of those and do whatever task you want. We know how hard it is to please everybody, so we thought long and hard on making it as flexible as possible.

BTW:
If your setup is limited to one specific platform, those scripts could be replaced with binary executables too.

Regards,
- Graeme -

No need to explain, I maintain Linux servers too. If I need to run some GUI app, I tend to setup a minimalist window manager too. These days I am quite fond of JWM (Joe's Window Manager).The look and feel resembles that of Windows (9x,2000)

Regards,
- Graeme -

Hans-Peter Diettrich wrote

To find out whether to use "there" or "their", try to replace it by "my"

Excellent, thanks. Afrikaans is so much simpler than English.

Regards,
- Graeme -

And no default way (freedesktop way) to setup desktop icons, menu icons etc etc etc ...

One could say that there is a perfect (GNUStep) way, which afaik works for multiple STEP windowmanagers.

Note that it could be that if windowmaker is not on the freedesktop list, GNUstep is.

In our previous episode, zeljko said:

The problem is of course freedesktop not being GNUStep compliant :-)

- nice and helpful bureaucracies that quickly update your package

if a product has fulfilled its goals, what "progress" is there to be made? ;)

updates/upgrades simply for update/upgrade sake are worthless... next thing you know, there'll be a flood of updates/upgrades that have had nothing more than the version number changed because folk think that it must have a new version and release every X days/weeks/months/years/etc... that's sad and suxorz... heck, i've got products that have been out for 10+ years and have had no new bugs found or features requested... what was released at the last release date was as clean and bug-free as it could be... i won't even mention how upset my alpha and beta testers used to get at me because there were no bugs for them to find... so... i created "bug" routines for them :P

know that feeling all too well... many times the fingers move slower than the brain and characters, phrases, and even whole sentences are lost in the ether :)

and remember that the difference between the last two is only the letter 't' ;)

and waist is what you put your belt around... waste is trash or non-productive time ;) ie: a thin female waist is a great thing to watch but a pile of waste is not :P