Slashdot Mirror

http://www.autopackage.org

Look at the target of the project:

Build packages that will install on many different distros

Packages can be interactive

Multiple front ends: best is automatically chosen so GUI users get a graphical front end, and command line users get a text based interface

Multiple language support (both in tools and for your own packages)

Automatically verifies and resolves dependencies no matter how the software was installed. This means you don't have to use autopackage for all your software, or even any of it, for packages to succesfully install.

There's nothing about your system that can't be tracked down by a little intelligent scriptwork. If package managers worked like that, then you'd be able to ignore them on occasion or even break small pieces and the rest wouldn't come tumbling down.

Right. In fact an easier way to look for a library is to scan the linker cache. Look, I'll show you:

/sbin/ldconfig -p | grep libfoo .

In fact, the code we use in autopackage is a little more involved:

/sbin/ldconfig -p | grep "${lib}\(\.[[:digit:]\.]*\)\?$" | awk 'BEGIN {FS=" => "} { print $2 }' | (while read; do test -f "$REPLY" && echo "$REPLY"; done)

This works because (unfortunately) if a library is not in the linker cache, it won't be usable by the system anyway so nothing is lost by not checking the filing system directly in this case. For python we do exactly what you suggest

Is anybody working on this? Is anybody interested in working on this?

In short, yes. You aren't the first one to think of this. In fact the approach goes back to the days of autoconf, but as far as I know my project is the first attempt to apply this to binary packages on Linux. See autopackage.org for details. It's essentially a lot of infrastructure and support code for packages, combined with a library of tests for common packages. Eventually we hope the library developers will maintain the "skeleton files" themselves.

Hmm, no, many distributors like RPM. It's a simple and convenient way to ship a few gigs of software on CDs with your distro and remain sane. I think you mean, users think RPM sucks, and this is where we can start discussing.

Your idea for a GUI to source tarballs has already been done, basically. There are programs like KConfigure that do it all for you, but they don't make installing from source any easier. Why not?

• Source tarballs don't contain dependency information. Or rather they do, but only in the form of configure checks, which are useless for actually resolving dependencies.
• Source tarballs are source code. That means installing the software takes ages, eats disk space and RAM, and so on.
• You typically end up with unstripped binaries.
• Some source tarballs cannot be uninstalled.
• This approach is useless for binary-only packages like (say) games.

The only real way forward out of this mess is to develop a portable binary packaging scheme that allows you to install packages on many different distros WITH dependency resolution. And of course, better developer education - dependencies have a cost. Depending on CVS HEAD of a library in a release is just a big nono. Keeping dependencies fairly mainstream, or better, optional, takes practice and a bit of forethought but can be done (see Wine for an extreme example of this approach).

PLEASE! Will someone serious about standardizing Linux installs do something about this... or desktop Linux will never take off.

You're welcome to help out. The project in my sig is one such approach - we're currently working on dependency resolution from a network.

Number of Linux distributions: There's no way to make a good installer that will install a commercial app on Linux and have everything work. There are too many dependencies for specific versions of libraries and things that would make this sort of thing worse than any kind of Windows DLL hell.

This is the primary reason I stopped using Linux as my desktop. Installing a program was the hardest thing being I'm not very compile savvy and don't plan to be. I'm hoping that autopackage solves this problem. And forget about RPMS. Once installing programs becomes a matter of mouse clicks (no term windows), then I'm sold.

Right. Let's just get this out of the way first - static linking is not the solution (not least because not all dependencies can be statically linked anyway).

So the "download a package and click on the icon" scenario will only work if clicking on that icon starts a program that does dependency checking, downloads dependencies off the internet, and then installs

That's exactly whay autopackage does. Well, almost. At the moment we don't do network retrieval, so if you're missing a dependency you have to drop it into the same directory as the thing you're trying to install. We're getting there though, slowly. It works for any reasonably sane distro (if it doesn't, it's a bug, so let us know).

This would be better, but not optimal, because you have to start downloading the package, wait for package to download, then start the install, then wait for the libraries to down load and install.

Correct. However, walk before you can run and all that.

It would be better to have act,act,wait,wait - same amount of time overall, but free's up the user to do something else (ie, workflow is controled by the user, not the computer).

autopackage has only one button for most of the install, "Hide", which [shudder] minimizes it to the tray. A suboptimal solution, but one we hope will encourage users to do something useful, like play games, while waiting for their program to install. In future, hidden mode will be the default.

Here's an idea. It is simular to how streaming integrates with the browser. Say we create a redirection file type whose contents is just the name (or url) of a debian package.

That works OK, but I think I have a better idea. Let's create a browser plugin that understands the Linux .desktop file format, can render PNG and SVG icons (not all that hard, the shlibs to do this are already installed for most users running kde or gnome) and so on. It displays an application launcher icon, just like the file manager would do, or the panel, or the menu....

Now the icon is drawn in grayscale. The user won't know what that means at first, but it shouldn't take too many encounters with this system for it to click - if it's grayscale, you're going to have to wait when you click it (because it's not locally installed). Users can click the launcher, and a pretty animation appears over it to let the user know something is happening. In a few seconds the installer UI appears, and asks (for instance), whether they have the root password, which subcomponents they want etc.

It only takes a few seconds for this screen to appear even on dialup because autopackage has a split design - the metadata that controls the install can be separated from the package payload and downloaded separately (well nearly, still a few bugs there). So, you just need to hang around for a few seconds, click "OK" and the window disappears - the icon gradually fades to colour as the package is installed.

All dependencies are calculated and retrieved behind the users back, while they get on with something else.

The install finishes. The program runs. They can of course drag the icon to their panel, menu, desktop, file manager, whatever. They can drop it onto a friends Gaim chat window, it appears the other end (as grayscale), the friend clicks it and the right package for them is downloaded.

It's like appfolders, except it doesn't suck.

The list does not analyze autopackage. Despite it's really recent, it has some interesting features, and as far as i tried it works really well.

Autopackage comes to mind.

from the site:
* Build packages that will install on many different distros
* Packages can be interactive
* Multiple front ends: best is automatically chosen so GUI users get a graphical front end, and command line users get a text based interface
* Multiple language support (both in tools and for your own packages)
* Automatically verifies and resolves dependancies no matter how the software was installed. This means you don't have to use autopackage for all your software, or even any of it, for packages to succesfully install.

As far as package management is concerned, there is one in the works. I've been keeping my eye on it this past year. It's supposed to install the same programs distro neutral. It's called autopackage. Here's from there FAQ:

autopackage is software that lets you create software packages for Linux that will install on any distribution, can be interactive, can automatically resolve dependancies and can be installed using multiple front ends, for instance from the command line or from a graphical interface.

Check it out!

In windows, I double-click setup.exe, a GUI pops up, I pick the destination and off it goes.

Absolutely. This type of thing is essential for Linux if it is going to gain widespread desktop use.

I know it's complicated. But it just has to be made simpler for the end user, no excuses.

Like everything in the OSS world, there are loads of different projects taking different approaches. Whilst this isn't a bad thing, eventually a standard needs to emerge, and the sooner the better. I think more people should help out with Autopackage, which seems to be taking the right approach.

I have more faith in GNU Autopackage myself.

I do apologise. I didn't make myself clear. What I meant was: Language bindings that work, and are useful for something other than feature checklist wars on slashdot.

In terms of working, useful language bindings KDE is a C++ environment only. Now kindly fuck off, loser.

autopackage - Linux portable packaging

Linux needs a MUCH better graphical interface (anti-aliased fonts, copy-cut-paste between applications) a decent program manager (Pray for Autopackage), and better hardware support. Oh, the day the RTFM mentality is laid to rest will be a BIG step forward for open source.

On the other hand, Microsoft needs to become better for security, stability, and development. Losing all the annoying bells and whistles (ala, the default installation of XP) would be a plus.

The real question is, which one will happen first.

"They're about true dependency resolution - if you can configure the make file, chances are you won't hit any snags when running the program, unlike certain other binary package format I know."

That's what the Autopackage project is about: sane autoconf-like depency resolution for binary packages.

And is anybody else seeing extreme slowness on Slashdot since OSDN moved across America?

By both his and your logic. Let's hear it for MacOSX. An OS that's easier to use than WinXP and being used by people who don't want to spend 99.99% of their lives computing. It doesn't have all the games or hardware of Windows, but lets hear it for the all powerful "ease of use" which will carry it through these tough arguments.

there's no global software installation system that Just Works Autoopackage has some good ideas, hopefully something like this will be implemented across most of the distros...

Linux has got the right idea - see how easy and powerful apt/ports/emerge is? One day, everything will be able to be installed in that way, and dependancy hell will be a thing of the past. At least, I hope so :)