Hi, long time ago I wrote there but I am still breathing/reading. The things that made us drop Bitrock for Autopackage is that to generate an autopackage, we only have to change the package version in one file and type one command and if Makefile is up to date all is created. With Bitrock we had to add files manually in the UI and that was pretty boring. Moreover, Autopackage was open source and Bitrock isn't. In addition, when using AutoPackage, all binaries are automatically compiled using a very old GLibc. As the libs are backward compatible, this work perfectly for all distributions. Anyway, the main drawback of Autopackage (which Bitrock had before) is its non RPM/DEB integration : the packages are managed by the AutoPackage manager. But in fact this isn't so critical as the RPM/DEB packages are better done when built by packages maintainers than by automatic systems. Don't forget that we also have "make deb/rpm" which can do bad quality generic packages. For Windows, the NSIS installer perfectly fits our needs with a powerful scripting engine. Bitrock system can be nice but I am afraid we loose our users if we give them the autopackage, NSIS and bitrock packages Phil
Youness Alaoui a écrit : > Hi 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. > On Sat, May 2, 2009 at 1:49 PM, Daniel Lopez <dan...@bitrock.com > <mailto:dan...@bitrock.com>> wrote: > > Hi Youness, > > I just saw your post on this via Google Alerts. If there is interest, > we can take a look at packaging aMSN together with all the > dependencies. > > http://www.amsn-project.net/forums/viewtopic.php?p=38159 > > We already do something like that for BitNami stacks > (http://bitnami.org) and InstallBuilder has come a long way from our > beginnings :) Just let us know if this is something you would be > interested in (maybe initially distributing alongside .package, to see > which one people like the most) and we can work on it > > Best regards > > Daniel > > -- > Daniel Lopez, CTO. http://bitrock.com > Confidential - All Rights Reserved. BitRock © 2009 > > > > > ------------------------------------------------------------------------ > > ------------------------------------------------------------------------------ > Register Now & Save for Velocity, the Web Performance & Operations > Conference from O'Reilly Media. Velocity features a full day of > expert-led, hands-on workshops and two days of sessions from industry > leaders in dedicated Performance & Operations tracks. Use code vel09scf > and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf > > > ------------------------------------------------------------------------ > > _______________________________________________ > Amsn-devel mailing list > Amsn-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/amsn-devel ------------------------------------------------------------------------------ Register Now & Save for Velocity, the Web Performance & Operations Conference from O'Reilly Media. Velocity features a full day of expert-led, hands-on workshops and two days of sessions from industry leaders in dedicated Performance & Operations tracks. Use code vel09scf and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf _______________________________________________ Amsn-devel mailing list Amsn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/amsn-devel
