AutoPackaging for Linux 623
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."
They ought to autopackage themselves a mirror (Score:2)
Aren't there enough (Score:2, Insightful)
Re:Aren't there enough (Score:5, Informative)
And we'll be available at #autopackage at irc.freenode.net if you have questions.
Re:Aren't there enough (Score:5, Informative)
And this is why autopackage is great. It doesn't tries to replace apt/rpm/gentoo, it just tries to be a good way of distributing software, and encourages developers to create their own "autopackage packages" so they work in every distro
Re:Aren't there enough (Score:3, Insightful)
Woah woah. Let me just stop and laugh for a moment. You're telling me that random developer X can do a better job of making a package than the people who develop the friggin' distro? Are you kidding?? Seriously, the idea that *more* cooks in the kitchen will somehow result in a "more coherent" set of packages is incredibly laughable...
Re:Aren't there enough (Score:4, Insightful)
They won't do "packaging" better, simply it will be better. The developer of project foo may say: "foo version 2.15-b depends on project bar version 1.1 to run properly", and everyone would follow it. Distros still could package themselves in a different way but that won't bee too common, and at that point people may tell "hey, your fedora package don't works properly in debian". My point is that a common package format
WONT SOLVE ANYTHING. Autopackage doesn't solve anything because it's a better format, but because it has a different philosophy. It doesn't matter how good are deb or rpm - they will NEVER work in another distro just because of their philoshopie
The purpose of autopackage (Score:5, Informative)
- "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 [autopackage.org]! Our project has existed for over 2 years now, and many people have asked us those questions. In short: autopackage is not meant to replace RPM/DEB/apt-get/etc.
If you have more questions, feel free to come over at #autopackage at irc.freenode.net
We'll be glad to answer your questions
Re:The purpose of autopackage (Score:2)
Please let non-root people install (Score:5, Insightful)
It's absurd that you need to enter a root password to do something as simple as install a user-space program - and it's absurd that package mangers only support dependancy checking for stuff installed in the main system directories.
At work, the main directories (/usr, /bin, etc) can only be accessed by the IT guys; but every department has a directory ("/usr/department/engineering", for example) of that memebers of that group can install software in. We have a newer version of Perl in ours. It really sucks that package managers can't help deal with the dependancies in an environmennt like this.
Re:Please let non-root people install (Score:2)
Re:Please let non-root people install (Score:5, Informative)
Check out the Flash demo. They actually demonstrate that capability-- the application installs packages under $HOME/.local/lib $HOME/.local/share, etc. I dislike cluttering $HOME with $HOME/lib, $HOME/share, $HOME/man, etc. -- installing these pieces under a dot directory to keep them hidden & organized is a great idea.
But I am also curious about allowing groups to install software under
Re:Please let non-root people install (Score:4, Informative)
Under the FreeBSD ports system, you simply set $PREFIX to wherever you want things to happen. While this is probably not obvious to grandma, it would just come to a script to
1) add $HOME/.programs to the relevant paths
2) add the "mypackage" script to $HOME/.programs/bin which sets $PREFIX and passess the rest of the argments.
It's been a few years since I've used dpkg, but I'm pretty sure that it had similar options, and I always assumed that rpms could do something similar.
hawk
Mirror of the autopackage website (Score:5, Informative)
Re:The purpose of autopackage (Score:5, Funny)
All Your Bandwidth Are Belong To Us.
Re:The purpose of autopackage (Score:4, Funny)
Crap! *now* what do I do?!?!?
... is completely unclear (Score:3, Interesting)
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 d
Re:... is completely unclear (Score:4, Interesting)
"Other dependencies are not so simple, there is no file that reliably expresses the dependency, or the file could be in multiple locations"
Yes, that's what virtual dependencies / capabilities in both rpm and dpkg provide. As for files moving around, that's what the FHS is for. Got a
But in reality, you don't encounter this scenerio untill you install rpms/ debs on another distro. Big deal: binary packages will always be built against specific library versions. Autopackage doesn't solve that.
"because RPM is, at the end of the day, a tool to help distro makers, they sometimes add new macros and features to it and then use them in their specfiles. People want proper integration of course, so they use Mandrake specific macros "
That's a human problem. You can't fix it with technology. Taking away the ability to have custom macros is a bad thing. Encouraging proper behavior is a better thing.
"Bad interactions with source code: because the current versions of RPM don't check the system directly, they only check a database"
You don't mean bad interaction with source code. Installing from source works fine, provided you know how to make install you can easily reate an RPM of most autoconf apps in about 2 minutes.
You mean bad interaction with non-packaged software. Again, that's a human issue, but one that's been solved better and better over time. Both OSS projects and proprietary vendors including Adobe's, BEAs, Macromedia etc. all release properly packaged binaries.
And frankly, I like having a database. I want to be able to find out what package was responsible for installing a file, and a URL where I can get a new version of the software. I like having a checksum of all my files at install time, so I can see if they've changed later. All of which autopackage doesn't do.
I don't like anything that encourages people to install unsigned applications from the internet, which autopackage does.
"a dependency does not encode any information on where to find it"
Yes, Great they kept that shit out of the dependency isn't it? Because what provides that capability isn't determined by the software. My app needs a webserver. That could be thhtpd, Apache httpd, Roxen, or whatever else. Rather than specifying what package provides that dependency, they simply list the depency. Three of my available packages say they provide a webserver capability. When a new webserver comes out, it will say it provides that capability too. Without requiring a new package of the thing that wants a webserver. Brilliant stuff!
Re:Clarify a point for me please (Score:3, Funny)
Re:The purpose of autopackage (Score:5, Interesting)
The first reason is the lack of dependency management. Because you are simply moving folders around, there is no logic involved so you cannot check for your apps dependencies.
OS X handles this at runtime. i.e. You can install the software, but the folder contents contain enough information for the OS to give you an error message when you run it. Usually this amounts to nothing more than "OS X 10.3 required!", but it could be more. FWIW, I think the lack of a "standard" set of OS services in Linux complicates this issue. Under OS X (and to a certain degree Windows), developers always know which libraries they can always depend on, and which ones they should bundle.
You'll note that bundled APIs on OS X and Windows tend not to duplicate each other across a given set of installed programs.
One obvious one is that there is no uninstall logic either, so the app never gets a chance to remove any config files it placed on the system.
This would be true on Linux, but it is NOT true on OS X. In OS X, the desktop integrates with the filesytem and learns via events when an application is added or deleted. This means that OS X users see file associations as soon as the program is added to the system, and they also see the deletion of those associations when the program is removed. It's all very seamless and prevents the dangling associations that plague Windows.
The OS X FS takes things one step further by storing file system IDs instead of path names for everything. This means that if I move my program from the Desktop to Applications, the associations will move with it. Similarly, if I have a file open and I move it, my file will save to the new location instead of the old one.
Another is that the app menus are largely determined by filing system structures. This means that it's hard to have separate menus for each user/different desktop environments without huge numbers of (manually maintained) symlinks.
1. An application menu IS just a bunch of glorified symlinks.
2. OS X handles this by having a system wide Applications folder for all users. If users wish to have private programs, they can drag them to their desktop or home folder.
3. The dock is the user's customized menu. The most commonly used apps are usually already there so that users don't have to hunt for them. If a user wants another app on his dock, he can drag it on there to create a shortcut. Shortcuts are deleted by dragging the icon off the dock or into the trash can.
What your FAQ should say is, "Unfortunately, the Linux design philosophy precludes the use of an appfolders system, as the services required to make such a system work are most likely unavailable on most installations."
Now with that cleared up, good job guys. I'm glad to see that someone is finally tackling my number one Linux gripe. (Check my Journal for more info.)
Re:The purpose of autopackage (Score:3, Insightful)
OK, I don't know much about Mac but I have to call bullshit on Windows there. Windows packages are constantly rolling their own "common" DLLs, with slight differences, overwriting identically-named DLLs from other packages and clobbering that package's symbols. "DLL hell" wasn't just a clever assonance someone came up with.
Re:The purpose of autopackage (Score:3, Informative)
Re:The purpose of autopackage (Score:3, Informative)
Re:The purpose of autopackage (Score:3, Interesting)
Some FAQ entries (Score:5, Informative)
# 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
Re:Some FAQ entries (Score:5, Informative)
# What's wrong with centralized repositories, apt style?
The system of attempting to package everything the user of the distro might ever want is not scalable. By not scalable, we mean the way in which packages are created and stored in a central location, usually by separate people to those who made the software in the first place. There are several problems with this approach:
# What's wrong with NeXT/MacOSX style appfolders?
One of the more memorable features of NeXT based systems like MacOS X or GNUstep is that applications do not have installers, but are contained within a single "appfolder", a special type of directory that contains everything the application needs. To install apps, you just drag them into a special Applications folder. To uninstall, drag them to the trash can. This is a beguilingly easy way of managing software, and it's a common conception that Linux should also adopt this mechanism. I'd like to explain why this isn't the approach that autopackage takes to software management.
The first reason is the lack of dependency management. Because you are simply moving folders around, there is no logic involved so you cannot check for your apps dependencies. Most operating systems are made up of many different components, that work together to make the computer work. Linux is no different, but due to the way in which it was developed, Linux has far more components and is far more "pluggable" than most other platforms. As such, the number of discrete components that must be managed is huge. Linux is different to what came before not only in this respect, but also because virtually all the components are freely available on the internet. Because of this, software often has large numbers of dependencies which must be satisfied for it to work correctly. Even simple programs often make use of many shar
Re:Some FAQ entries (Score:4, Insightful)
Most applications shouldn't need to modify the OS to run, and for that minority that do, OS X still does have packages. This is how haxies and so forth work.
The only valid objection I've seen to bundles is the one about how a user shouldn't be able to install random software from the internet. This is a pretty good point, but I fail to see how that, even in a system that uses an apt repository, you would be able to prevent a user from downloading and installing some random RPM from a website. You would have to have a severely crippled OS.
Re:Some FAQ entries (Score:5, Insightful)
The thing that concerns me about the DMG exploits, is that they were caused by the fundamental design of the system not simple typos/poor coding practice. Having appfolders integrate with the system by registering file associations/URL handlers silently through the shell seems like the obvious way to handle this stuff in an "install free" environment, though really it's just doing the install at a later time. But it had unintended side effects which were devastating for security.
The problem is, to solve this you either have to go back to some explicit action integrating software with the system, or pile on more hacks to try and solve the security exploits. Apple chose both - Tiger boasts an improved installer, iTunes comes inside a package etc. But the approach they took with Safari reminds me of Internet Explorer: cover up a flawed technology like ActiveX with more and more hacks and security restrictions that somehow always managed to leak.
You are right that most applications should not need to modify the "system" to run. This is the principle behind authentication-less installation, which we only approximate on Linux with the install to $HOME feature in autopackage. Figuring out the exact set of permissions that are safe for installers to have and then enforcing them is somewhat tricky: both Windows and MacOS X are riddled with programs that demand the administrator password which implies that so far, nobody quite identified the sweet spot.
Re:Some FAQ entries (Score:4, Insightful)
It's pretty simple: if the package isn't signed by someone you trust, refuse to install it. This has the been the behaviour in up2date since it was created, and yum does the same thing. I'd be very surprised if apt/get (at least on systems where package signing is expected) didn't do the same.
RPM itself, when used directly, currently throws up a warning if a package isn't signed by someone trusted, but (uunlike up2date / yum / etc) still installs it. This behavior may change in future tho.
Re:Some FAQ entries (Score:3, Funny)
But I thought that was our national policy. Certainly seems that way historically.
I don't know about this (Score:2, Insightful)
Encouraging users to install Comet Cursors for Linux seems to me like
Re:I don't know about this (Score:2)
Re:I don't know about this (Score:5, Insightful)
Sorry if this sounds insulting, but your attitude seems really narrow-minded and short sighted. The whole reason the computer is such an incredibly useful tool is that it is so flexible and extendable. YOU might manage to get everything you need out of the software included in your distro, but do you really expect the big distros to anticipate every single need of every single user? A lot of people who are not computer experts have specific application needs that the vast majority of users don't share. Should a good distro include a version of GAMESS [ameslab.gov] just because I want to do a theoretical chemistry calculation? Or maybe the people who make distros should assume (correctly) that if I am one of the .0001% of computer users who would want to use that program, I should just go download it myself?
"This may sound elitist of me, but if you can't figure out how to do it now, you probably aren't capable of making that sort of decision."
Yes, you sound incredibly elitist, as if it is impossible to be smart and NOT a computer expert. There is a big difference between knowing enough about one's Linux distro to install a program and having enough common sense to find programs on the internet with minimal risk of installing malware. If I google search for software that simulates microwave spectra of asymmetric top molecules (and by the way there are quite a few) what are the odds I'm going to find spyware masking itself as what I'm looking for?
Re:I don't know about this (Score:3, Interesting)
The way it works out in practice on Debian is that, for most people, once it's mature enough to be included in the distro, it's part of the distro. Until then, you probably want to install it from source anyway, which is an option you always have.
Should a good distro include a version of GAMESS just because I want to do a
Re:I don't know about this (Score:5, Insightful)
This is hardly the point of the project.
The point of the project is to eliminate problems for developers in packaging their software to be able to run across distros.
The fact that it makes it easier to relieve dependency hell is a bonus for those users who want packages not included in their distro.
Anybody who says EVERYTHING they'll ever need is included in their distro is just being a troll. Because it simply is not possible that ANY distro is "finished." And a lot of people don't want to wait months until something they want shows up in a repository.
If Windows did that, everybody would still be using DOS.
Finally, the notion that it is somehow "evil" to install software from the Net is just stupid. The Net exists to distribute information - and programs are part of that.
Practically everything I use on the Windows side of my machine was downloaded off some Web site or another - and I have several gigs of stuff on my Linux side to explore yet which also has the same origin.
And I have NEVER had a spyware/virus/trojan problem from such software. (Although I have had software that simply screwed up the machine due to stupid programming.)
Users get spyware and other crap from stupid, pointless little programs offered by commercial entities because the user acts like a kid in a candy store when offered something "free". If the users really knew what freeware was about and where to get anything they need, they would be less likely to do stupid stuff like downloading a calendar program loaded with spyware.
While it is true that CORPORATE users should be restricted from downloading any damn thing they see (unless it has a productivity purpose), home users certainly should not be.
Your solution smacks of the paternalism I hate about Windows. You want your distro to control your machine just as much as Gates wants to control Windows users.
Sorry - not acceptable.
Missing the point (Score:3, Insightful)
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
Re:Missing the point (Score:3, Interesting)
The factor blocking the deployment of "malware" to Linux isn't the intractability of Linux software installing, but the low population size of unskilled users, and the low explotiation value of that population (same as the largest reason there are few "viruses").
Re:Some FAQ entries (Score:3, Insightful)
You can say that again. In fact, this has exactly been my gripe with linux, including the so-called user-freindly distro's.
Apt-get, rpm, whatever - but if you are just browsing the Net and want to install something it's a real PITA, with Linux. There is no equivalent of an
Where does everything get autopackaged to? (Score:2, Insightful)
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
Installation for Windows (Score:3, Insightful)
Re:Where does everything get autopackaged to? (Score:5, Insightful)
Re:Where does everything get autopackaged to? (Score:2)
Which brings me to the question, why would any free software author bother with autopackage when all decent distros provide mechanisms such as apt-get? And what about non-x86 architechtures. In my view autopackage support is _wasted time_. Any self-respecting user of my software already u
Re:Where does everything get autopackaged to? (Score:3, Interesting)
I think if I were an upstart package, and nobody were packaging me for their distro, I would want to be converted to an autopackage.
Re:Where does everything get autopackaged to? (Score:5, Informative)
There's a mirror of the autopackage website's information here [dur.ac.uk].
Yes, we need this!! (Score:5, Insightful)
The reason is that most of these packaging solutions, while great for developers and those who want detailed knowledge of the inner workings of their systems, simply suck when given to mortal users.
And they don't handle a number of edge cases too well... What if you want different versions of some software to coexist on the same system? What if you want ten different versions of a library? Yes, these can all be handled by current stuff... but not very well. It's bad enough that when we install software here, we actually get the rpms or whatever and then re-package them ourselves to serve our needs.
A packaging solution that actually works is desperately needed.
Re:Yes, we need this!! (Score:5, Insightful)
It seems to me that {NeXT,Open,GNU}step-style apps are both good for developers, and great for mortal users. Drag an app (it's just a file) to your Applications folder, double-click it to run, drag it to the trash to delete. They also handle your "edge cases" (multiple installed versions) just fine.
They're actually quite a bit simpler for users because an app is just a file -- a first-class object in the system. You don't need a special program just to "install" and "uninstall" programs. You don't need ugly hacks like the "start menu" (Gnome or KDE's reimplementation of it). Users think an app should be a first-class object, and it's perfectly feasible, so as developers we should make that the case.
The autopackage FAQ has "what's wrong with NeXT/MacOSX style appfolders", but it seems to consist mostly of hand-waving and straw men. They don't seem to understand how NeXT/Mac apps work, e.g., w.r.t. linking.
Re:Yes, we need this!! (Score:3, Interesting)
Packages are much more complicated conceptually (files all over the place for example) than appfolders.
Then why use packages? I think the reasons are:
1. Efficiency of HD space and memory
2. Some things are easier to do with files all over the place.
In the end, it's millions of people who have to put up with the confusing situation of packages just so that a few very smart developers can have it easier. That's the wrong way around! Even those same developers USE the program many more ti
Re:Yes, we need this!! (Score:5, Informative)
Could you elaborate please? Of course it's possible to build a system that uses appfolders, NeXTStep is one, however:
The only person who has really done serious work with appfolders on Linux is Thomas Leonard, an extremely smart man who was behind the ROX desktop. Note that appfolders aren't a Mac or NeXT invention, they were done by RISC OS back when I was a wee kid.
As Thomas found out, dependencies are kind of a tricky problem with appfolders. His solution was ZeroInstall, a very nice piece of work I must say. However it had issues, as software often does, and now he is designing something called the "Injector". This has quite a few concepts similar to autopackage, namely management of interfaces and dependencies. So in the process of "fixing" appfolders to have all the features people wanted, he ended up with something that vaguely resembles systems like autopackage and apt-get. Note: that doesn't mean to imply that the Injector is useless or anything, it's not and has some good ideas. I encourage people to check it out!
Just be aware that appfolders tend to evolve into installers eventually. They did on DOS, RISC OS, and of course on MacOS X as well (iTunes comes in an installer and it's not the only one ....)
Wrong Paradigm (Score:5, Insightful)
The current Linux model of distros integrating and authenticating software from upstream authors helps ensure the security of the userbase as well as providing installation ease of use. This is something we should be proud of rather than trying to imitate the technically inferior competition.
Re:Wrong Paradigm (Score:2)
Re:Wrong Paradigm (Score:2)
Re:Wrong Paradigm (Score:4, Insightful)
I guess you would only be happy if we just pulled everything down from SVN/CVS and built from source.
Re:Wrong Paradigm (Score:3, Insightful)
Yeah, just like if the ActiveX-plugin paradigm was broken, nobody would use IE, right?
Most users have *no* clue if a piece of software is designed incorrectly or not, it has exactly zero bearing on whether the masses use a particular piece of software or not.
Re:Wrong Paradigm (Score:5, Insightful)
I'll tell you this now, the packaging system is not the factor that people base their decisions to run windows on.
Yes there are some things about Windows that suck but MSI and InstallShield installers are not a example.
When you are installing from installshield, you're basically saying: 'Hello random executable from the internet (even if you are signed by someone), here, overwrite any of my libraries you'd like, with whatever obscure or customised version you want. Oh, and while you're at it, do whatever you want to my registry...'
I guess you would only be happy if we just pulled everything down from SVN/CVS and built from source.
That's a strawman attack. He didn't say anything like that - in fact it's the complete opposite of what he was arguing.
Re:Wrong Paradigm (Score:5, Insightful)
If there's one thing I love about Linux is the way I can download/install a software using a single command (or a GUI tool) in most distros.
Even Gentoo, not exactly regarded as the most user friendly distro, allows one to download & install a software by doing:
emerge XYZ
That's it. Same goes for Mandrake, Debian, Fedora, etc. End-user distros like Linspire even go further by allowing you to browse through all available software, look up the description and then perform a "one-click" install.
I think that's great, and a whole lot better than the windows (and mac os x) alternative where you have to look for software on the web, try to see if they contain malware, download them, run the installer, etc.
One of the advantage of the system is that the upstream provider (i.e. usually your distro) checks the package for validity. The packages you download won't contain virii or spyware (even if those were to exist on Linux) because the provider would likely not allow them...something MS would certainly do if they controlled the software ppl are downloading.
I know some packages are hard to install (Gnome for example) but for the most part, I feel software installation is a lot easier on Linux than on Windows, unless you go the CVS/SVN route and compile everything yourself.
At least on Mac OS X, you usually simply drag and drop the Application in the Applications folder and that's it. While not perfect, it's a whole lot better than Windows.
Re:Wrong Paradigm (Score:3, Insightful)
For example, I needed a swi-prolog installation for a small class project a couple days back. I needed the GUI library, which means the package available in Gentoo (swi-prolog-lite) would not be sufficient. Thus I had to download the .
Re:Wrong Paradigm (Score:3, Interesting)
I don't know much technical detail about software packaging, either in Windows or Linux, so I can only speak based upon my experience. My experience has been that package management in Linux is much preferable to Windows. When I used Windows 2000, I would often install software that later could not be fully or completely uninstalled (broken uninstall), and often software that was installed would make undesirable and unauthorized changes to settings like file associations. I'm not talking about malware he
Re:Wrong Paradigm (Score:5, Insightful)
Nobody's trying to copy the Windows paradigm with autopackage. What they're trying to do is break down that barrier to cross-distribution software releasing. Your average desktop user does not want to compile software. Dropping to a terminal, cd pathtoapp, tar -jxvf whatever.tar.gz, cd newpath,
"If they can't compile they should run Windows" is a stupid, backwards attitude, and autopackage is trying to fix it. Relying on upstream content providers is dangerous -- what happens when you disagree with your upstream provider? You have to switch distributions? Pat recently dropped Gnome support for Slackware -- I still run gnome. I do it with a third-party package from dropline. Is that broken? No.
The way to fix the problems you describe is to educate users, not to remove their usage priveleges. Teach people not to install untrusted software -- and teach them how to tell what software to trust! Don't just slap their hand and yell NO.
Re:Wrong Paradigm (Score:3, Interesting)
That's content, not programs. Completely different. And when it's linux iso's They're always the same because they are checked against the hashes. The end result is the same thing as having a very fast ftp.
When I develop a program that takes random input and outputs Frank & Earnest cartoons, I don't want to have to wait for some Board of Linux Usage Oversight to give my 5k perl script the Stamp of Approval
Autopackage is the wrong solution (Score:3, Insightful)
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
For more information on autopackage... (Score:5, Insightful)
- 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 [freshmeat.net] with some more info and downloading.
This is a great thing for Linux (Score:2, Insightful)
It would be nice... (Score:2)
Re:It would be nice... (Score:3, Interesting)
Mirrordot of Flash (Score:5, Informative)
I have to say this is like a godsave for linux. Most layusers will want some easy installation like this instead of using something like Yum (even if it is a GUI front-end to yum like GYUM). This is one giant step towards a viable desktop linux - and I believe that it isn't a replacement for apt/yum/[INSERT YOUR FLAVOR HERE] but uses them under the hood.
Before everyone starts bashing it and says that apt or emerge or whatever they use is the way to go, seriously think about it - one click installation, from a FRIENDLY user-interface, and easy to manage system for installing and uninstalling programs. Now if this were part of the base install on many distributions and some sort of standard was established (seriously, we need standards) I can probably convince my scared-of-Linux-because-it-is-hardcore friends to actually try Linux out.
One Autopackage... (Score:3, Funny)
Conflicts with existing package managers (Score:4, Interesting)
I'm presently running Debian. I've briefly played with making my own .deb files so I'd be able to install some of my own things without necessarily completely losing track of everywhere they were scattered. With all of the extra meta files that need editing, the source packages versus binary packages, and everything else, though, the whole process of designing a .deb package looked a bit too structured and complicated for me to bother learning about... at least within the time I was prepared to spend.
If AutoPackage has a straightforward way to generate a simple package, such as from a tar.gz file, I might find it very helpful. What I'm wondering about, though, is how bad does it get when two package managers conflict? eg. Apt and AutoPackage might end up trying to control the same file, get mixed up between what manager is providing a particular dependency (particularly if Apt tries to grab a package that AutoPackage has already installed), or whatever else.
It also sounds a bit of extra work having two sets of commands to manage packages on one system, so ideally (in my world), I guess AutoPackage would wrap around Apt or whatever other manager, and invoke it when appropriate. Does AutoPackage just fight for control when there are conflicts, or does it integrate with other package managers nicely?
The server seems to be very slashdotted right now, so I can't do much reading up on it. Does this sort of conflict thing turn out to be much of a problem?
Re:Conflicts with existing package managers (Score:5, Informative)
For post-1.0, native package manager integration is on our todo list.
When it ties in with RPM, I'll take a look (Score:3, Interesting)
This isn't meant to be a criticism, I realise that they plan to do this and it takes time, to do everything that everyone wants is a long process
Re:When it ties in with RPM, I'll take a look (Score:3, Informative)
BackPackage (Score:3, Insightful)
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 [apt-get.org].
Re:BackPackage (Score:5, Interesting)
I suspect you are thinking of something like Conary. However ... that said, a distributed and decentralised package management system is what autopackage is all about. Autopackages can resolve dependencies in a manner that does not require large monolithic databases: the packages themselves know where to go to find their dependencies if they're missing (and in future they'll be able to use yum, apt-get etc as well just in case).
Basically the apt-get type model doesn't work too well once you start having say >50 repositories all together, as co-ordinating the overlaps becomes too much of a nightmare. A much less tightly coupled system works better, which is what we have here.
Comment removed (Score:4, Interesting)
The idea of packages is bad. (Score:3, Insightful)
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.)
Where Can I... (Score:3, Funny)
I tried out an autopackage... (Score:3, Interesting)
Mirrordot (Score:4, Insightful)
-----
Check out the Uncyclopedia.org [uncyclopedia.org]:
The only wiki source for politically incorrect non-information about things like Kitten Huffing [uncyclopedia.org] and Pong! the Movie [uncyclopedia.org]!
Re:nextgen already here: emerge (Score:2, Interesting)
Re:nextgen already here: emerge (Score:5, Insightful)
Re:nextgen already here: emerge (Score:3, Insightful)
DIE FANBOY MODS (Score:4, Funny)
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 does not scale. (Score:2, Insightful)
Re:nextgen already here: emerge (Score:5, Insightful)
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.
Re:nextgen already here: emerge (Score:2)
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.
Re:nextgen already here: emerge (Score:3, Insightful)
Re:nextgen already here: emerge (Score:5, Interesting)
Re:nextgen already here: emerge (Score:5, Insightful)
Re:nextgen already here: emerge (Score:3, Insightful)
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.
Re:nextgen already here: emerge (Score:3, Interesting)
Don't tell these people [gentoo.org].
Re:apt-get? (Score:2)
Re:apt-get? (Score:2)
Re:That's right. apt-get works. (Score:5, Insightful)
MIRROR IS HERE (Score:3, Insightful)
Re:MIRROR IS HERE (Score:2, Informative)
This is missing. [dur.ac.uk]
Re:Be like OSX (Score:4, Insightful)
#apt-get update
#apt-get dist-upgrade
Badabingbadabangbadaboom. It's done. Happy days are here again.
Re:Be like OSX (Score:4, Insightful)
hahaha
hahahahahahaha *gasp* HAAAAAAAAAHHAHAHa
Now Debian is my favourite distro by far but I'm never gonna pretend that the package system is solid. Having way to many times been in the position where some little thing breaks and dpkg and apt just choke totally (to the point where I can't install something because I some package is broken and I can't uninstall that package because the damned uninstall-script needs something installed first).
The long and short of it is No, that's not how you "fix" dependencies in Debian. A lot of editing obscure files, handrolling temp replacement packages and so much swearing I need to put a parental advisory sticker outside my appartment is.
Not as simple as that (Score:3, Insightful)
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 li
Re:Linux (Score:3, Interesting)
Re:What about Java applications? (Score:3, Informative)
Re:plenty of UI and Usability mistakes (Score:3, Informative)
Dialogs same size - not sure there's any point to this. Dialogs that don't fit their content are just weird. Making them all the same window is technically very hard because of the need to run different programs to re-authenticate etc. Yes yes, excuses, but software is compromise.
No cancel button: where is the cancel button? You cannot cancel an install, so there should not
Re:Interesting criticism of the OSX DMG (Score:3, Funny)
- Valid signature from 92429807C9853C0744A68B9AAE07828059A53CC1
Do you want to trust all of these keys to sign interfaces?
Not unless you're prepared to ask me this question every time you download and run anything off the net.