Re: [Mono-devel-list] Looking for people to do Mono/autopackage integration
Hello, They look every bit as professional and clean as a commercial MacOS software site, but when you click the Download $COOL_APP link you get a tarball! For those programs that do not require native libraries, we could probably generate a Mono-based installer that can use console or Windows.Forms based installations. There is really nothing stopping us from building a Mono installer for applications that can be relocated, the challenges I think are: * Write the code that installs software: should this be an executable program, or should it be a package format with a special extension that a minstall command can process? * Applications that use this process should probably follow the Application Guidelines, but take things a step further: be completely relocatable and break with the Unix tradition of prefixed-based configurations. I would go as far as advocating the creation of a standard to create OSX-like bundles for Linux and encourage the various desktop efforts to include support for bundles. The first addresses software that requires it to be adapted to the target system, register itself somewhere or modify some system files; The second is for fully self contained software. A prototype should not take longer than a day. Miguel ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-devel-list] Looking for people to do Mono/autopackage integration
Miguel de Icaza wrote: For those programs that do not require native libraries, we could probably generate a Mono-based installer that can use console or Windows.Forms based installations. Well, I can see why this would be tempting for you but my advice is don't: a) You'd be rewriting what already exists, for what benefit? b) Autopackage is already being used by projects, it has small but rapidly growing mindshare - it'd be nice to have some standardisation across projects so users get a consistent experience c) Writing installers *sounds* easy, but by the time you've made it work on N^2 distros, fixed all the bugs, added digital signatures, a nice user interface, support uninstalling/upgrading native packages if they already exist etc etc, it turns out to be a lot of work. Autopackage has been in development for a long time now. It is true that a lot of this time was spent 'fixing' the design decisions of the GCC and glibc people, which I guess .NET does not suffer from, but still ... much of that time was also spent writing the bootstrap code, documentation, su/sudo wrappers, GTK+ and Qt based GUIs, integrating LZMA compression, getting professional artwork etc. * Write the code that installs software: should this be an executable program, or should it be a package format with a special extension that a minstall command can process? With autopackage it's both, but leaning more towards the former. For maxiumum ease of use, the first time you run them they'll download and install the runtime code itself. Then after that, you can just click on .package files to install them. This flexibility is why we were able to switch to a much improved compression algorithm for the 1.2 release, for instance. * Applications that use this process should probably follow the Application Guidelines, but take things a step further: be completely relocatable and break with the Unix tradition of prefixed-based configurations. Autopackages are always relocatable and we provide an easy way to install stuff to $HOME if you don't have the root password. We provide simple kits you can integrate with the program to make them relocatable, as well as complete documentation on how to do it. You can see this in action here: http://autopackage.org/flash-demo-install.html This code should be in glib really, but the independent kits are useful for now. I would go as far as advocating the creation of a standard to create OSX-like bundles for Linux and encourage the various desktop efforts to include support for bundles. This has been discussed many times on autopackage-dev, and we have invented at least three different ways of implementing appfolders on Linux. Some require integration with GNOME/KDE, and other techniques are fully backwards compatible with existing desktops. So far we've never implemented it - it turns out that basic stuff like being able to get root on a wide variety of distributions in a fully graphical way took up all our time so far. However, it was designed from scratch to support multiple user interfaces and we already have fairly complete blueprints for not only the current wizard-style UI but also an apt-get style command line UI and a MacOS X style bundle UI. The first addresses software that requires it to be adapted to the target system, register itself somewhere or modify some system files; Most software does, in my experience, even for trivial things like menu entries. A prototype should not take longer than a day. Heh, famous last words ;) The autopackage prototype only took a week, and that included uninstallation, verification and dependency checking. Turning it into a product took three years. There's no need to re-invent the wheel here. thanks -mike ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-devel-list] Looking for people to do Mono/autopackage integration
We already have a for all distros installer (that uses bitrock). But it'd be really cool to see this use autopackage. Yes, I saw. Bitrock is a good product. My main aim here is to get Mono applications themselves using graphical installers - if the Mono runtime itself is also autopackaged and so can be depsolved in then great, but if not then there's still benefit. I think the best way to start would be from the top down. It'd be nice to do a package of MonoDevelop and then see what can be made easier to do with helpers in autopackage, etc. Agreed. From what I know of Mono the following things might be an issue: * DLL mappings * the GAC * Ahead of time compilation * Detecting assembly versions (we use a variety of ugly hacks to get ELF DSO versions) But there's only one way to find out, and that's to go ahead and do it. I'd love to but right now, can't ... so hopefully somebody will decide to have a go. thanks -mike ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-devel-list] Looking for people to do Mono/autopackage integration
Hello, For those programs that do not require native libraries, we could probably generate a Mono-based installer that can use console or Windows.Forms based installations. Well, I can see why this would be tempting for you but my advice is don't: a) You'd be rewriting what already exists, for what benefit? Raise the bar in the state of art of Linux installation. b) Autopackage is already being used by projects, it has small but rapidly growing mindshare - it'd be nice to have some standardisation across projects so users get a consistent experience Am thinking of something that normal users can use, not something that copes with every possible angle of software dependencies, but going for a simple OSX-like setup. c) Writing installers *sounds* easy, but by the time you've made it work on N^2 distros, fixed all the bugs, added digital signatures, a nice user interface, support uninstalling/upgrading native packages if they already exist etc etc, it turns out to be a lot of work. Well, Ximian's business was largely managing software installation and all of its related angles as part of its red carpet product, so am not terrified by this. Certainly doing a general purpose tool for all kinds of software (native c, dependencies, mix of code) is needed, and I think autopackage fits nicely in this area. What am suggesting is something Mono-specific for small applications that can take care of average applications being developed. Think about Perl, Ruby and Python's frameworks for doing software installation: they are not frameworks for doing *everything* but they can do a pretty good job for *most* of their software. Autopackages are always relocatable and we provide an easy way to install stuff to $HOME if you don't have the root password. We provide simple kits you can integrate with the program to make them relocatable, as well as complete documentation on how to do it. Such a document would be invaluable. My feeling is that autopackage focus is in adapting existing software which is prefix-designed to be relocatable. Where can I find the documents/tutorials for this? We might want to change Mono's installer to use something like this, as it currently breaks for 2.x uses. What I would like to do is break with the prefix tradition. So far we've never implemented it - it turns out that basic stuff like being able to get root on a wide variety of distributions in a fully graphical way took up all our time so far. However, it was designed from scratch to support multiple user interfaces and we already have fairly complete blueprints for not only the current wizard-style UI but also an apt-get style command line UI and a MacOS X style bundle UI. What I care about the most with bundles is being compatible with OSX in as much as possible. Am talking about the file system structure, not really the actual dmg image, ie Chess.app. The advantage of this is that we could distribute cross-platform bundles that would work on OSX and Linux. The dmg problem would be handled by a mime-type handler, so am not too worried about that. Most software does, in my experience, even for trivial things like menu entries. Yeah, this might have to live in a Mono.InstallationServices dll. The autopackage prototype only took a week, and that included uninstallation, verification and dependency checking. Turning it into a product took three years. There's no need to re-invent the wheel here. Yeah, but like I said, autopackage is for seriously complicated apps; Am thinking it more for pure Mono apps which have much less dependencies and we can safely assume `Mono is in your path' Miguel ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-devel-list] Looking for people to do Mono/autopackage integration
a) You'd be rewriting what already exists, for what benefit? Raise the bar in the state of art of Linux installation. That's certainly a worthy goal, but I'd like to think we already did - easy to use one click installs are something we put a lot of effort into. If you haven't watched the Flash demo, I'd recommend it: http://autopackage.org/flash-demo-install.html Am thinking of something that normal users can use, not something that copes with every possible angle of software dependencies, but going for a simple OSX-like setup. Well, it's not drag/drop, but it *is* just as simple: * Click on a link in a webpage * Click Open in the firefox file download dialog (actually you can tell firefox to always open this filetype) * It downloads ... there is a simple confirmation window: http://autopackage.org/screenshots/newshots/gtkfe-intro.png * You click Install and then enter your password (or not): http://autopackage.org/screenshots/newshots/autosu-ask.png * That's it. You get a summary screen at the end: http://autopackage.org/screenshots/newshots/gtk-yaydone.png The user doesn't have to think about dependencies, or install paths, or anything really - the only decision to make is Do I know the root password and this is easy, either you do or you don't. On MacOS X you must make some more decisions: * Do I click the app right now, while it's inside the DMG? * Or ... do I drag it to the dock? * Or ... the /Applications directory? Actually only the last one is correct, but that's something you just have to know. So I don't think the autopackage UI is complicated. What am suggesting is something Mono-specific for small applications that can take care of average applications being developed. Think about Perl, Ruby and Python's frameworks for doing software installation: they are not frameworks for doing *everything* but they can do a pretty good job for *most* of their software. Sure, but your typical Mono app does have dependencies: the Foo# library bindings if nothing else. Well, you could ship them all as part of the Mono platform and that'd work, but bleeding edge apps would still have problems. A large platform combined with automatic graphical dep resolution for very new libraries: http://autopackage.org/screenshots/newshots/gtkfe-retreive.png seems like a nice balance. Such a document would be invaluable. My feeling is that autopackage focus is in adapting existing software which is prefix-designed to be relocatable. Sure, we try and make this easy because autopackages are relocatable as a rule. But that's just an artifact of most C programs not being so, there's nothing C specific about it. Where can I find the documents/tutorials for this? We might want to change Mono's installer to use something like this, as it currently breaks for 2.x uses. Actually, this document is for an older version: http://autopackage.org/docs/binreloc/ The CVS version of binreloc is simplified considerably and can generate different styles of code (eg, raw C vs glib style). It also has less bizarre memory management semantics. Unfortunately it's not documented yet, but the basic theory is the same: provide convenience functions for finding your own path, getting the prefix from it, and then appending other paths (all in one function if you like). What I would like to do is break with the prefix tradition. Yes, me also. That's why we have it as a rule. What I care about the most with bundles is being compatible with OSX in as much as possible. Am talking about the file system structure, not really the actual dmg image, ie Chess.app. Given that bundles need to be customised anyway, for instance to have Aqua compatible artwork, I'm not sure it's worth trying to make Linux apps the same right now. It'd be better to provide an installer EXE for Windows, an autopackage for Linux and an bundle for MacOS X. The dmg problem would be handled by a mime-type handler, so am not too worried about that. Right. But MIME type handler for GNOME 2.10? or GNOME 2.8? Or KDE 3.x? Or all of them? Yeah, but like I said, autopackage is for seriously complicated apps; Am thinking it more for pure Mono apps which have much less dependencies and we can safely assume `Mono is in your path' Well, not really, right now autopackage is used for really quite simple apps packaging-wise: Gaim, Inkscape, AbiWord: none of them are too terrible. I tell you what. How about I try and package a Mono app tonight, and I will show you how trivial it really is. There's a quickstart document here: http://autopackage.org/developer-quickstart.html which shows you all the basics in one page, and it also covers basic advice like don't depend on CVS versions of unstable libraries ;) Ignore the C++ warning, this is relevant only for the stable 1.0.x series, but we have much improved C++ support in CVS that will make dealing with the ABI change fully automatic. I
Re: [Mono-devel-list] Looking for people to do Mono/autopackage integration
On Wed, 2005-07-27 at 15:22 +0100, Mike Hearn wrote: * Autopackage supports dependency resolution. Some users on some distros don't have any easily accessible packages for the Mono runtime, or if they do they may not know where to get them. By packaging not only applications but also the runtime and the various Foo# bindings, this problem can be mitigated: distros that ship Mono out of the box don't change and the packages will use whatever is already installed. For users on distros that don't ship it, autopackage can depsolve the runtime onto the users system. We already have a for all distros installer (that uses bitrock). But it'd be really cool to see this use autopackage. I think the best way to start would be from the top down. It'd be nice to do a package of MonoDevelop and then see what can be made easier to do with helpers in autopackage, etc. -- Ben ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
