Tool to build installer for desktop applications

[Archos]

Go needs a tool to build installers that can be used for the final
user. It's now an extra and hard work if you want to distribute your
application in the different platforms but it would be great if it
could be easily handled from Go.

Now, it isn't important for the most of people because they're working
in libraries (stuff to be used by another developers), or in servers
but it's very import for desktop applications.

What do you think about it?
Does the Go team is going to build it?

[Archos]

On Apr 5, 11:23 pm, Peter Thrun <peterth...@ymail.com> wrote:
> > Go needs a tool to build installers that can be used for the final
> > user.
>

> There are one or more installers for each of the major desktop
> environments.  Is there a reason not to use the existing installers?
For Windows, you need a Windows system if you want build an installer
for your Go application.

Then, each linux distribution has a different system (1) to install/
uninstall appications but they have built mainly to handle the
dependencies respect to libraries for each application, which is
unnecessary for Go apps.

All that means much work to know and handle all those different
installers. What we get is a great difficulty to distribute our
applications.


(1)
aptitude/apt-get: Debian/Ubuntu
pacman: Arch
pkgtool: Slackware
portage: Gentoo
yum: Cent OS/Fedora
zypper: OpenSuse

I don't know about Mac OS but I'm sure it will use another package
manager

[Archos]

On Apr 6, 12:00 am, Peter Thrun <peterth...@ymail.com> wrote:
> > For Windows, you need a Windows system if you want build an installer
> > for your Go application.
>

> You need a Windows system to test your application.
This is not true when you have code independent of the system and
architecture.

> Then, each linux distribution has a different system (1) to install/
>
> > uninstall appications but they have built mainly to handle the
> > dependencies respect to libraries for each application, which is
> > unnecessary for Go apps.
>

> A Go application can have dependencies on outside libraries.
(1) Go applications are built statically.
(2) The main work of those installers in Linux systems is to handle
the dependencies.

[Archos]

I know that you can have extra resourses/assets in your application
but it doesn't need those packages manager to handle it.

[DisposaBoy]

I hate to be the one to point it out, but all your assertions are overly-simplified(i.e not much better than wrong). I can't comment on the situation for Windows and OS X but for Linux it should definitely not include such tools. That is all.

 

[Archos]

On Apr 6, 4:11 am, DisposaBoy <disposa...@dby.me> wrote:
> I can't comment on the
> situation for Windows and OS X but for Linux it should definitely not
> include such tools. That is all.

But why should not be included a tool to manage the static packages in
all unix distributions?
Do you have any solution? If no, then is better than developers have
to know/handle near of 10 different package managers before of
distribute the applications?

[Sebastien Binet]

Archos <raul...@sent.com> writes:

better leave that to experts
ie: just wait for a nice packager from some linux distro to come
forward.

or, if you want to do it yourself,
use OBS: https://build.opensuse.org/

-s

[DisposaBoy]

To get it right you're going to have to package it *for* the particular distribution. I general your binaries are static, but if you do any networking there is a chance that there is some dynamic linking going on. If you create a package for rpm and deb you've covered most of the bases as far as installation is concerned but you're still just throwing guess-work at it because you assume all distros are the same which is not the case. The best solution is to either distribute source or a tarball which makes it easy for distributors to repackage things correctly.

[Archos]

Distribute source code is only acceptable when your software is free
(like beer).

And, at least for me, waiting for another people to repackage your
application isn't a good option when you want launch fastly your
application. In addition, it can takes a long time until an app. been
aproved, and then to be repacked.

Those package managers were right in another time, when there were
lesser number of building of programs. And they're valid when you
distribute the source code but I want that closed software can be
installed in my system.

[Archos]

On Apr 6, 10:23 am, Sebastien Binet <seb.bi...@gmail.com> wrote:

> Archos <raul....@sent.com> writes:
> > On Apr 6, 4:11 am, DisposaBoy <disposa...@dby.me> wrote:
> >> I can't comment on the
> >> situation for Windows and OS X but for Linux it should definitely not
> >> include such tools. That is all.
> > But why should not be included a tool to manage the static packages in
> > all unix distributions?
> > Do you have any solution? If no, then is better than developers have
> > to know/handle near of 10 different package managers before of
> > distribute the applications?
>
> better leave that to experts
> ie: just wait for a nice packager from some linux distro to come
> forward.

An expert gives an objective view. He gives his own view.

> or, if you want to do it yourself,
>  use OBS:https://build.opensuse.org/

In fact, I've thinked in building a service to repackage easily.

[Jan Mercl]

On Friday, April 6, 2012 12:00:44 AM UTC+2, Archos wrote:

Go needs a tool to build installers that can be used for the final
user. It's now an extra and hard work if you want to distribute your
application in the different platforms but it would be great if it
could be easily handled from Go.

Go needs a tool to build installers as much as e.g. gcc needs it.

[Archos]

If Go were followed that concept then we would not have the toolchain
that allows install source code in our systems (go get/install)

[Aram Hăvărneanu]

Go already offers the best installer technology, it's called compress/gzip.

--
Aram Hăvărneanu

[Archos]

On Apr 6, 11:52 am, Aram Hăvărneanu <ara...@mgk.ro> wrote:
> Go already offers the best installer technology, it's called compress/gzip.

Of course, using that technology you can install automatically your
application in the different systems and uninstall it when you desire.

[Jan Mercl]

What's the connection between go get/install and a "tool to build installers"?

[Aram Hăvărneanu]

>> Go already offers the best installer technology, it's called compress/gzip.
> Of course, using that technology you can install automatically your
> application in the different systems and uninstall it when you desire.

Yes, I can use unzip(1) and rm(1) or equivalents for that system.

--
Aram Hăvărneanu

[Archos]

We can have a tool for un/install binary packages independently of the
system.

[Archos]

And you can also change the configuration settings in the Windows's
registry

[Aram Hăvărneanu]

> And you can also change the configuration settings in the Windows's
> registry

Compress/gzip is great because you don't have to change any
configuration settings in the Windows registry.

--
Aram Hăvărneanu

[Jan Mercl]

On Friday, April 6, 2012 1:23:57 PM UTC+2, Archos wrote:

> What's the connection between go get/install and a "tool to build
> installers"?
We can have a tool for un/install binary packages independently of the
system.

You want to sell binary blobs? Great. Good luck. Go for it and write yourself a tool to build an installer or use some already existing if there's any. Just, when *you* need something, please don't put it in a way that *Go* needs that something when it's not true.

[Archos]

Do you know that you can distribute closed software without sell it?
Are you speking in name of the Go team? If no, then your comment is
insignificant.

I want to know if Go team has thinked about it or they're going to
write such tool? To avoid an extra work.

[Archos]

It's clear that you don't know the Windows system or you have not
distributed applications in that system

[Jan Mercl]

On Friday, April 6, 2012 1:48:31 PM UTC+2, Archos wrote:

On Apr 6, 12:33 pm, Jan Mercl <0xj...@gmail.com> wrote:
> On Friday, April 6, 2012 1:23:57 PM UTC+2, Archos wrote:
>
> You want to sell binary blobs? Great. Good luck. Go for it and write
> yourself a tool to build an installer or use some already existing if
> there's any. Just, when *you* need something, please don't put it in a way
> that *Go* needs that something when it's not true.
Do you know that you can distribute closed software without sell it?

Commercial or not, who cares? You're completely free to do whatever you like with your code/blobs, not anyone else's business and also not relevant here.

 

Are you speking in name of the Go team? If no, then your comment is
insignificant.

Are you speking in name of the Go team? If not, then your assertion that Go needs a tool to build installers is insignificant.

No I'm not serious. Just showing how such ad hoc "rule" kicks right back.

 

I want to know if Go team has thinked about it or they're going to
write such tool? To avoid an extra work.

Then why to make strange claims about what Go needs? Just ask about what you want to know. Much simpler, less trolling ;-) 

[Archos]

On Apr 6, 1:09 pm, Jan Mercl <0xj...@gmail.com> wrote:
> On Friday, April 6, 2012 1:48:31 PM UTC+2, Archos wrote:
>
> > On Apr 6, 12:33 pm, Jan Mercl <0xj...@gmail.com> wrote:
> > > On Friday, April 6, 2012 1:23:57 PM UTC+2, Archos wrote:
>
> > > You want to sell binary blobs? Great. Good luck. Go for it and write
> > > yourself a tool to build an installer or use some already existing if
> > > there's any. Just, when *you* need something, please don't put it in a
> > way
> > > that *Go* needs that something when it's not true.
> > Do you know that you can distribute closed software without sell it?
>
> Commercial or not, who cares? You're completely free to do whatever you
> like with your code/blobs, not anyone else's business and also not relevant
> here.
>
> > Are you speking in name of the Go team? If no, then your comment is
> > insignificant.
>
> Are you speking in name of the Go team? If not, then your assertion that Go
> needs a tool to build installers is insignificant.
>
> No I'm not serious. Just showing how such ad hoc "rule" kicks right back.

Like a Go developer, I could think that anything is right or could be
helpful. Are you speaking again in name of the Go team to say what we
have to question here?

> > I want to know if Go team has thinked about it or they're going to
> > write such tool? To avoid an extra work.
>
> Then why to make strange claims about what Go needs? Just ask about what
> you want to know. Much simpler, less trolling ;-)

Like I just say, I question what you I want and I think about a tool
which could be very helpful, in this case, to helping to distribute
our programs.