[Gambas-user] Gambas Software Farm in revision #6676
B Bruen
bbruen at ...2308...
Tue Nov 25 11:20:10 CET 2014
On Mon, 24 Nov 2014 14:11:54 +0100
Benoît Minisini <gambas at ...1...> wrote:
> The recent news about Gambas Software Farm:
>
> - Many bug fixes.
I am now getting quite excited about this. At the moment it appears that it will be a very good solution to our current very manual way of distributing new and updated software to our client base.
>
> - The farm configuration (server list, identities) has been removed from
> the IDE option dialog, and is now in its own dialog. That way, the code
> of the software farm is independent, and will be put in its own
> executable (gambas3-farm) in the future.
Definitely looking forward to the stand alone version! However, the configuration now looks a lot more logical. (I was having concerns about the modal nature of the whole publishing thing.)
>
> - Voting is now possible by clicking on the star button, as soon as you
> are identified on the server. Each user can assing zero or one vote for
> each software. The number displayed beside the star is the total number
> of votes
>
One thing that isn't immediately apparent is that clicking on the star a second time seems to remove your vote?
> - Installing is not done.
I still maintain that autotools is the way to go. It is, as far as I know, distro independent and complies with the desire to make the whole menagerie based on "source code visibility". The installer, apart from the nastiness checking previously posted, could use the existing code in the IDE to create an autotools package and then run the ".reconf;.configure;make;su(do) make install" circus to install it.
>
> As for installing software, here are my thoughts:
>
> - The farm server will extract the ".project" file for the submitted
> software to know about its component dependencies (not done).
I am not sure what you are implying here but I think you are saying that if a published project has dependencies on an unpublished component, for example a non-native component then it will not be installable until the said non-native component is also published?
>
> - When installing, the farm client will download the ".project" file to
> check these dependencies. If they do not match, an error message will be
> displayed, and the installation will abort.
And here I think you are saying that if a published project has dependencies on any component that is not installed on the local machine then the "installation" would fail with an appropriate message. In short, "Here be beasties!" or in Aussie "Been there, done that, seen the movie, bought the T-shirt ". The best solution we have come up with is, again autotools, including extra checks in the script along the lines of:
AC_MSG_CHECKING(for required components - sysinfos.gambas)
if !(test -e /usr/lib/gambas3/sysinfos.gambas); then
AC_MSG_RESULT(Not found)
AC_MSG_ERROR(Required libraries must be installed BEFORE this package)
else
AC_MSG_RESULT(Ok)
fi
With a bit of thought I could probably modify our autotools installer to generate these required checks automatically...
>
> - In the future, the error message could be replaced by an automatic
> installation of binary packages depending on the distribution. I need
> help for that: for each distribution, I need to know how to install a
> binary package, and if the distribution follows the gambas binary
> package naming convention.
As mentioned by Kevin, I would eschew binary installs. Too much danger.
>
> - If there are dependencies of other softwares, then a recursive search
> of all the dependencies is done, and the corresponding software must be
> installed first.
We have found that too hard. Better a message "Can't install, you need the zyxxy component to be installed first".
>
> - The source package is downloaded, and stored in something like
> '~/.local/gambas3/farm/<farm server>/'.
Hmmm. Not sure. I have a feeling "~/Downloads" may be more friendly, or a configurable target.
>
> - The software is compiled on the user's computer, and the executable is
> installed in '~/.local/gambas3/bin/'.
Q'est que se? (whatever, it's been 40++ years since high school French!) Surely the compiled executable should go into the (default) project directory..
I think that promoting a compiled program to executable status is a matter for the user. Again, given Kevin's comments, I would like to see an ability to
1) download the source code to a selected area
2) review the code via the IDE, with some possible assistance regarding "this program converses with the internet at large" etc
3) make my own decision as to whether to install the said program in any automatically executable directory.
4) only install it with a locally executed su(do) command or utility.
>
> - A *.desktop file is created and installed in
> '~/.local/share/applications' so that it appears in the desktop menu.
I think this should only happen if the project is a "Normal".
>
> Waiting for your comments!
You got em.
>
> --
> Benoît Minisini
>
Most of the above is based on my intent to use our own farm server, which I wont use until this whole thing works fully. But as I said, it is looking good.
best regards
Bruce
--
B Bruen <adamnt42 at ...626...>
More information about the User
mailing list