New FB version.

For other topics related to the FreeBASIC project or its community.
Landeel
Posts: 736
Joined: Jan 25, 2007 10:32
Location: Brazil
Contact:

Postby Landeel » May 12, 2011 12:10

Detect available frontends:

Code: Select all

if [ $(type -P zenity) ] ; then echo found zenity;fi
if [ $(type -P kdialog) ] ; then echo found kdialog;fi
if [ $(type -P Xdialog) ] ; then echo found Xdialog;fi
if [ $(type -P dialog) ] ; then echo found dialog;fi


Detect KDE:

Code: Select all

if [ $(pidof ksmserver) ] ;then echo Running KDE ; fi
Galeon
Posts: 563
Joined: Apr 08, 2009 5:30
Location: Philippines
Contact:

Postby Galeon » May 12, 2011 12:41

I think we could just warn the user if /usr/bin/fbc or /usr/local/bin/fbc exists, and provide a link to a forum post or wiki article explaining the situation or a way to remove the old installation, or install an uninstall script for the user to use if he wants to manually remove the manually installed compiler, or something like that.

But I do agree with marcov that it may remove an installed compiler from another package, because there's no way we can tell. Anyway, I might get surprised if this will be added to the package, and if I don't know of this situation, because commonly I have other compilers for FreeBASIC around (I have one installed as a deb with checkinstall, another one as cross-compiler, another one as standalone for testing purposes, etc).

TJF wrote:
marcov wrote:Though I agree with Galleon that this is a bad practice.

This sentense doesn't help anybody. For me it's only bla-bla, until you'll provide an alternative.

Eh?! I don't see anything wrong expressing your own opinion.
TJF
Posts: 3546
Joined: Dec 06, 2009 22:27
Location: N47°, E15°
Contact:

Postby TJF » May 12, 2011 13:32

Rather than the fbc version i guess it should check the place where fbc is installed (locate).

If it's /usr/bin/fbc, it's allready an package installed version. It gets overwritten (no problem).

If it's /usr/local/bin/fbc (or something else), then it's a script-installed version. That needs to get removed/renamed (or this will run instead of the newer one). For the standalone version some other files needs to get handled as well? (I don't know.)
marcov
Posts: 2939
Joined: Jun 16, 2005 9:45
Location: Eindhoven, NL
Contact:

Postby marcov » May 12, 2011 15:12

TJF wrote:
marcov wrote:Though I agree with Galleon that this is a bad practice.

This sentense doesn't help anybody. For me it's only bla-bla, until you'll provide an alternative.


Not doing this is a perfectly fine alternative. It is simply not doable to manage all files on a system from an application installer perspective. You simply can't do much more than the package system provides, since that is all you can rely on.

And I gave a reason directly following it, but I'll rephrase it:

Even if you find a file, you don't know where that file came from, and only have a handful of feeble heuristics that something is wrong. And for that you will have the package break when there is a wrong assumption, bitrot or bug in the script.

TJF wrote:
marcov wrote:This way you don't even check if the compiler is part of a different package. IOW you are not even 100% sure it is not from a different debian package that also contains FB.

That's why the script should offer different possibilities to solve the conflict (or cancel the installation).


It would break systems that try to run the install unattended. Big chance that Debian/Ubuntu won't allow this in.

If you really think this problem is your major management/support problem, simply install a script with the package, and make a system out of asking the output of the script. (the system profile) in any support platform (maillist, forum, tracker etc).

At least when that breaks, you don't have to do a new release, just put a new version of the script online.

But that is something else then running it as default, and get all the flak if it causes problems.

TJF wrote:
marcov wrote:If I look at the manpage it sounds like it belongs to either GTK or GNome.

I doesn't belong to GTK (haven't seen anything about this yet). So it should be GNome.

So if zenity is GNome, it should be avialable on most GUI distros. When the preinst script doesn't find zenity, it's a non-GUI system and the script can use a text based UI at the console. So KDE is the open issue now.


It might be a non GNOME, non KDE gui too. IOW run from GUI (no textconsole), but no kdialog or zenity. And it might be run as part of some packaging tool, or more way installer. And of course there are the Centos users that run age old gnomes.

Anyway, while I know you judge input on who writes it, not on content, at least take this hint: check with some ubuntu source (maillist or so) if they actually encourage such scripts before putting a lot of time in it.
marcov
Posts: 2939
Joined: Jun 16, 2005 9:45
Location: Eindhoven, NL
Contact:

Postby marcov » May 12, 2011 15:18

TJF wrote:Rather than the fbc version i guess it should check the place where fbc is installed (locate).

If it's /usr/bin/fbc, it's allready an package installed version. It gets overwritten (no problem).

If it's /usr/local/bin/fbc (or something else), then it's a script-installed version. That needs to get removed/renamed (or this will run instead of the newer one). For the standalone version some other files needs to get handled as well? (I don't know.)


I'm not entirely sure, but IIRC some Linuxes (Gentoo, Archlinux?) follow BSD practice to install all packages in /usr/local and leave the main / prefix for the base system.
Landeel
Posts: 736
Joined: Jan 25, 2007 10:32
Location: Brazil
Contact:

Postby Landeel » May 12, 2011 16:06

"type -P fbc" will tell where fbc is currently installed.
Maybe the script could simply rename fbc to fbc.old only if it's not in /usr/bin, and show a warning.
TJF
Posts: 3546
Joined: Dec 06, 2009 22:27
Location: N47°, E15°
Contact:

Postby TJF » May 12, 2011 17:05

Landeel wrote:"type -P fbc" will tell where fbc is currently installed.
Maybe the script could simply rename fbc to fbc.old only if it's not in /usr/bin, and show a warning.

The warning first. Tell the user that there is a conflict and ask him to decide on rename or kill (or do nothing).
Landeel
Posts: 736
Joined: Jan 25, 2007 10:32
Location: Brazil
Contact:

Postby Landeel » May 12, 2011 17:16

Just one problem, I have no idea how to interrupt the installation from the preinst script.
TJF
Posts: 3546
Joined: Dec 06, 2009 22:27
Location: N47°, E15°
Contact:

Postby TJF » May 12, 2011 18:22

Landeel wrote:Just one problem, I have no idea how to interrupt the installation from the preinst script.

What about exiting with an error value?
Galeon
Posts: 563
Joined: Apr 08, 2009 5:30
Location: Philippines
Contact:

Postby Galeon » May 13, 2011 8:50

IMO doing something like this will only bring more problems. And installing packages is not something you can just stop whenever you want, unless you want to spend the time helping those users if that happened.

I don't even see this as a major issue. Well, you installed it yourself so don't expect something automatic and the world will sort everything for you.

My opinion at least hehe.
TJF
Posts: 3546
Joined: Dec 06, 2009 22:27
Location: N47°, E15°
Contact:

Postby TJF » May 13, 2011 11:02

Galeon wrote:And installing packages is not something you can just stop whenever you want, ...

There is the prerm script as well, which gets executed before removing an older package (if any). This scipt might be a better choise to check for a non-package-installed FreeBasic version. See:

http://www.debian.org/doc/debian-policy/ch-maintainerscripts.html
Landeel
Posts: 736
Joined: Jan 25, 2007 10:32
Location: Brazil
Contact:

Postby Landeel » May 13, 2011 12:21

prerm

Code: Select all

#!/bin/bash

oldfbc=$(type -P fbc)

title="FreeBASIC Installer"

text="The installer have detected another FreeBASIC version installed in $oldfbc.\nYou will have to move, rename, or uninstall $oldfbc, in order to get the new version running."


if [ $oldfbc ]
        then echo fbc is installed in $oldfbc

   if [ "$oldfbc" != "/usr/bin/fbc" ]
           then
           if [ $(pidof ksmserver) ]
                   then echo using kdialog
                           kdialog --title "$title" --sorry "$text"
                   else echo looking for zenity
                           if [ $(type -P zenity) ]
                                   then echo found zenity
                                           zenity --title "$title" --warning --text "$text"
                                   else echo using dialog
                                           dialog --title "$title" --msgbox "$text" 12 48
                           fi
           fi
   fi

        else echo fbc is not installed.
fi



How about this? It's just a warning.

Feel free to rewrite the message, because my english sucks. :P
TJF
Posts: 3546
Joined: Dec 06, 2009 22:27
Location: N47°, E15°
Contact:

Postby TJF » May 13, 2011 13:43

Landeel wrote:How about this? It's just a warning.

Very good, it seems you solved the issue with the differend messagers!


IMO a warning is confusing. The installer continues and writes it's files to HD. The user gets two versions of fbc, examples, includes, ... on his box. Then, he may be unsure which folders or files should be removed and he may end up with two uncomplete versions.

From my point of view it's better to cancel unpacking until the conflict is solved. (If we cannot help solving the conflict, we can avoid brocken installations at least.)

What about this text:

Code: Select all

text="FreeBASIC detected at\n\n$oldfbc.\n\nFirst, since this is a non-package-installed version, move, rename, or uninstall it in order to get this new version running.\n(You may run 'install.sh -u' or 'install-standalone.sh -u' in your archiv folder.)\n\nUnpacking canceled!"
marcov
Posts: 2939
Joined: Jun 16, 2005 9:45
Location: Eindhoven, NL
Contact:

Postby marcov » May 13, 2011 13:58

I would say that dialog should not be the "else" category.

So it should be more

Code: Select all

 if .. kdialog
    do kdialog
  else
   if zenity
    do zenity
  if console
    do console
  else
    some failsafe option
end if
end if
end if


This because otherwise some unknown GUI or packaging tool (e.g. during setup) would be broken by popping up dialog without an associated TTY.

Keep in mind that it is possible that packages are installed in a limited GUI preboot environment when they are installed from CD.[/code]
Landeel
Posts: 736
Joined: Jan 25, 2007 10:32
Location: Brazil
Contact:

Postby Landeel » May 13, 2011 14:52

Keep in mind that it is possible that packages are installed in a limited GUI preboot environment when they are installed from CD.


Maybe if we detect if Xorg is running and fall back to dialog if it's not.

For some reason "pidof Xorg" doesn't work.

Is "pidof X" good enough?

Return to “Community Discussion”

Who is online

Users browsing this forum: No registered users and 7 guests