Please provide an ebuild for AutoPackage. It is a installer framework, like MSI, and I believe it could compliment Gentoo very well. It has just reached 1.0. Go to http://www.autopackage.org for more info.
Do we really want to support this junk? Debian have rejected it for Alien already, with good reason... (http://kitenet.net/~joey/blog/entry/autopackage_designed_by_monkeys-2005-03-28-14-20)
I fail to see the good reason. They seem to state its because of lack of documentation. Well <a href="http://autopackage.org/api/index.html">here is the API documentation</a>. If we are so insecure about trusting code (like we're really auditing all code we're importing anyways), or if we want to use our own interfaces to do this stuff the gentoo way or whatever, why don't we create a chroot jail and implement the API to where it calls our stub functions or something, and we extract the information we need from that?
Although, I might add that doing what I mentioned above would make flow control not fun to deal with. Really though I would just rather have a way for distros (other than gentoo) to be able to download an ebuild right click on it, and install in more of an autopackage way.
Sure, autopackage may have a pretty GUI, but it is not suited for Gentoo. Programs may not work due to the amount of flexibility that Gentoo provides (programs compiled with different versions of gcc may not link with each other, for example).
not a portage issue
No ebuild here, don't see any need for this either -> WONTFIX.
Of course it would be nice if these packages could be installed like ebuilds, so that portage can keep track of them. I'm thinking about gcpan and crossdev. But the first step should be to get this available as a standalone application, like rpm, to do its own package management and without any guarantees about nice integration with portage. I just stumbled over their homepage, and at least relaytool sounds like a thing I'd like to try out when developing software. I'd be willing to try creating an ebuild, but as far as I can tell, there are no source tarballs, the sources are only accessible through their cvs, and they are moving that to svn right now. I'd probably wait till the svn is up and running, to avoid doing things twice. (In reply to comment #2) > why don't we create a chroot jail chroot could be a problem if the app needs to see what files are present to do its dependency calculation. Perhaps a tightened and adjusted version of the portage sandbox would be more helpful. But imho that's an issue for a hardened USE flag, I think we need an ebuild first.
