Hey Daniel,
It's me again... I wrote you this message back in May and I didn't get any
response, I guess you just missed it or it went to your spam folder, so I'm
resending you these little questions...
I think we'll be releasing the 0.98.1 release of aMSN very soon and I'm
seriously considering switching back to bitrock!
In addition to the questions I had below (don't forget to read the forwarded
message!), I'd like to add this question :
You said that you would invest time in it, and it looks as if the bitrock
team would build the aMSN installers for us.. As far as I'm concerned, I
always thought that you'd just give us a license and we'd have to do all the
hard work in order to create our installers, etc... Am I wrong? Are you guys
willing to help us out creating a installbuilder configuration for aMSN (At
least for the first release, then we'd have to maintain it ourselves for
subsequent releases) ? That would really help, but I didn't think that you
guys would be willing to do something like that for free.. I wouldn't have
asked if you didn't say :
"we could give a try to create both the binaries for aMSN and the
installers, just wanted to check beforehand that there is interest (as we
will spend a substantial amount of time on this)"
Hope to hearing from you soon!
Thanks for your great support and take care! :)
KaKaRoTo
---------- Forwarded message ----------
From: Youness Alaoui <kakar...@kakaroto.homelinux.net>
Date: Thu, May 7, 2009 at 3:11 PM
Subject: Re: BitRock packages for AMSN
To: Daniel Lopez <dan...@bitrock.com>
On Sun, May 3, 2009 at 7:50 AM, Daniel Lopez <dan...@bitrock.com> wrote:
> Hi everybody,
Hi again Daniel,
>
>
> First I want to bring you up to date on the status of BitRock. It has
> been over 5 years now and the installer has certainly improved. To
> address your concerns:
>
> > no deb/rpm (or other native package management system) integration
>
> We support integration with the native package manager,
oh great! On the website it says rpm integration only.. is it outdated?
>
>
> > no (or bad) 64bit support,
>
> We provide native 64bit installers if you need them
good!
>
>
> > autopackage has some great tools for building all our binaries with ABI
> stable versions of gcc so it works with everyone.
>
> We do not offer such tools, we concentrate on just the packaging side
> of things. Having said that, we have developed quite a bit of
> expertise in packaging software so it runs across as many different
> distribution versions as possible, we may be able to help here
that's good, anyways, like I said, we could build with autopackage and use
its generated binaries... we already need to build it before packaging so we
would just have to do it with apgcc instead of gcc...
>
>
> > the installbuilder was very immature and quite difficult to work with (no
> recursive add of a directory for example)
>
> The GUI has never been a strong point of the installer. Though we have
> improved it quite a bit, people prefer to use the XML file directly
> using Emacs
That's nice, do you have any docs on the xml format so we can have a look?
it would be nice if we could specify full directories and excluded files
(like we currently have in our makefile) so we could say 'take this whole
directory but ignore this file from it'.
>
>
> Once the user installs the app, it can easily remove it running the
> uninstaller
>
> > I guess that we could build the autopackage binary, install it and create
> > the bitrock installer using the binaries from the autopackage install...
>
> That is certainly an option. One thing that I would strongly suggest
> that you consider is bundling a Tcl/Tk interpreter with aMSN as well
> as many other dependencies as possible. The increase in download size
> will pay itself many times over with reduced support costs. Think of a
> ".app" in OS X, it just works for most people most of the time... If
> other people want integration with underlying operating system or
> other versions of libraries they can always use the native
> distribution packages or compile from source.
Yes, the .app in OS X or like we do for windows is good because it just
works for most users, however for linux I would not recommend that.. many
linux users are very picky on how they install their software and they
wouldn't want two version of tcl/tk.. also note that we would need
gstreamer, farsight, glib, etc.. there is quite a lot of dependencies that
come into play so bundling everything is not really a good idea for linux
users since linux has a nice package management system...
Does bitrock allow integration with the native package manager in terms of
dependencies? like for example automatically doing 'apt-get install tcl8.5
tk8.5 libglib2' etc.. Or does it at least have a way to do some pre-install
hooks or something so we can test if the deps are there? Autopackage allows
us to write some code for checking dependencies, so it can check if tcl/tk
is installed and if not it tells the user and tells him how to install it. I
wouldn't want to loose that functionality.
>
>
> Also, I wanted to clarify that although we come from an open source
> background, Installbuilder itself is not open source. We give free
> licenses to open source projects such as aMSN.
>
> http://www.gnu.org/licenses/gpl-faq.html#GPLCompatInstaller
>
> In this case we could give a try to create both the binaries for aMSN
> and the installers, just wanted to check beforehand that there is
> interest (as we will spend a substantial amount of time on this)
Yeah, we know you're closed source.. lephilousophe might be a bit too
pro-OSS but I don't think it really matters as long as it does the job! I
also like it when companies try to encourage and help open source, so it's
nice to see you giving out free licenses to open source projects.
there's definitely interest in returning back to bitrock! It's just that
there are pros and cons and it's hard to make a decision (and change is
always scary for people).
Thanks,
KaKaRoTo
>
>
> Best regards
>
> Daniel
>
> > How funny, when I saw your email this morning, I thought "what a
> > coincidence, I was just thinking of bitrock yesterday night"... but it
> looks
> > like google alerts was behind this! I didn't know about google alerts, it
> > looks like a nice google feature! :)
> > Anyways, yes there is interest. I was actually just thinking that we
> might
> > have a second look at bitrock now. We liked bitrock a lot at the time,
> but
> > it had its limitations so we switched to autopackage. Now might be a good
> > time to switch back to bitrock, or as you suggested, provide both
> binaries!
> > Well, we'd have to discuss this with the other memebers of the team,
> since I
> > can't exactly remember what was missing from the bitrock installer that
> made
> > us use autopackage, but if I'm not wrong, the few issues I can remember
> are
> > :
> > - no deb/rpm (or other native package management system) integration
> > - no (or bad) 64bit support,
> > - autopackage has some great tools for building all our binaries with ABI
> > stable versions of gcc so it works with everyone.
> > - the installbuilder was very immature and quite difficult to work with
> (no
> > recursive add of a directory for example)
> > I just took a quick look to your features list and it looks like you have
> > rpm integration but no deb integration, but it also says that it has .deb
> > generation! So I'm not too sure, I don't know much about all this, so
> maybe
> > if you can provide us with more info, it might help! Does it just
> generate a
> > .deb for us, or does it generate/install the .deb out of the installer in
> > order to install on the user's systems? in other words, do we provide a
> > single binary which will install a .deb/rpm on user's systems, or we'd
> have
> > to provide a .deb, a .rpm and the bitrock installer?
> > Also, there seems to be some differences between distributions, so is it
> > even possible to have a single .deb file that would work on debian,
> ubuntu
> > hardy/intrepid/gutsy/etc... same would apply for the .rpm (would it work
> for
> > mandrake, mandriva, redhat, fedora core, etc...) ?
> > About the 64 bits support, we realized that autopackage seems to have a
> few
> > problems unfortunately, so if you can provide a good 64 bit support, we'd
> be
> > glad!
> > Concerning the tools autopackage provides, you may want to have a look at
> > them : http://autopackage.org/aptools.html especially apgcc, I know
> there
> > are some other tools we use, but Philippe Valembois would know better
> than
> > me.Basically it compiles the whole thing with some very old version of
> gcc
> > that is ABI stable so it will work for people with old and newer versions
> of
> > the libc, it also does some magic stuff for us...
> > I guess that we could build the autopackage binary, install it and create
> > the bitrock installer using the binaries from the autopackage install...
> > I can already assume that the installbuilder has come a long way since
> then
> > and that all the small issues we had with it are already fixed or less
> > annoying than before.
> > Once a user installs the app, does he have an easy way to uninstall it?
> > Assuming you don't have system integration, then is it like an uninstall
> > application that they can launch, or is there some kind of package
> > managmeent system like autopackage does?
> > I'm CC-ing the amsn-devel mailing list, this way others can see this, and
> we
> > can get a more informed answer about the subject!
> > p.s.: Just an FYI, In this screenshot :
> > http://installbuilder.bitrock.com/right-to-left-screenshot.html The
> title
> > bar doesn't seem to support RTL correctly, so if that's fixed, maybe you
> > should regenerate the screenshot.
> > @amsn-devel subscribers: please use reply all for Daniel to see our
> > responses, thanks.
> > Thanks!
> > Youness.
>
------------------------------------------------------------------------------
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf
_______________________________________________
Amsn-devel mailing list
Amsn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/amsn-devel
