Hi everybody, I apologize for the delay in following up. Yes, you are correct, we will provide you with a free license but also help create and maintain the installers (or as you mention we can create the first build and you can maintain the rest).
> 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 Our main limitation is time (we are still relatively small company). We come from an open source background (Apache, Mono contributors) and this is one way we can give back. We also work on BitNami.org as time permits. So how do you want us to get started? Do you already have binaries/documentation/thoughts about what you want the installers to look like? Should be have the conversation in the list, separately, IRC? Please see below for answers to your other questions Best regards Daniel >> > 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? Yes, we do offer 'deb' and 'rpm' creation. Integrating with the package database with a regular installer is only supported for RPM (that is, you install with the GUI installer wbut it still shows with rpm -ql, etc.) > 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... Ok, that is up to you, what you think is best. > 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'. You have a manual and a reference document in the docs/ subdirectory of the installation. We currently do not offer that level of filtering when packaging, but what you can do is run a Tcl script in <preBuildActionList> that cleans up and prepares the distribution tree for packaging. We can also implement that filtering, but it may take us a little bit. > 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. We do not have built-in actions for that, but we have hooks so you can write those dependency checkings. The main issue is implementing the logic for each one of the supported platforms (which exact package names and versions). You do not need to tie that up to the installer, either. For example, we could include a Tclkit, unpack it and run a 'pre-flight' Tcl script that you write that gives you complete control over checking dependencies, installing missing packages and so on. On the other hand, and specially because you have so many dependencies, it may be good to have at least one version that has 'everything and a pony' even if it takes 30Mb if that guarantees it will work. > 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. Thank you! We do not want to limit anybody's choice, it is also always possible for people to install some other way, we just think having nice installers will allow more people to enjoy aMSN (and, personally what I find more interesting, reduce the support cases from people who cannot get it to work) > 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). We can just give it a try, see how 'the experiment' goes and then you guys decide :) Best regards Daniel ------------------------------------------------------------------------------ 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
