|
Description
Support a standard distribution neutral installation format. AutoPackage is a good choice for this I think. But I don’t like the idea of it being all in one file. Otherwise you’ll have a huge installation file for programs like photoshop and various games if they are ported over to linux. And once you give an easy way for software authors to install their commercial software into Ubuntu, or any linux version that supports this format, that is great then. I’m sorry for those who will say to just put it up on a repository, but that will not work for these kinds of programs. How can you possibly include every single program from every software author out there? You can’t. Plus these are usually customized for the distribution the repository is supposed to be for. And then at that point you’re just rebuilding the wheel. Why waste all that time? Plus you are trying to make Ubuntu into an embedded system, and embedded systems have their limits like this very point. Now this is not a replacement for apt-get, but is a complement for it I think. Apt-get will be used to install software available on the repository and for updating system files like the kernel. But AutoPackage can support software that isn’t on the repository.
Tags:
(none)
Attachments
No attachments.
Duplicates
Comments
|
drinkypoo wrote on the 28 Apr 08 at 02:36
| |
Autopackages work fine on Ubuntu, I have several installed now.
|
|
Ssdg wrote on the 28 Apr 08 at 07:36
|
The point is THERE IS a linux standard, rpm but it was decided without asking debian guys (at the moment of the choice debian was the major linux distro).
The market will decide. So, let's see how long will software vendors take to build rpms, debs or both.
|
|
pyrates wrote on the 28 Apr 08 at 08:07
|
This is why I like AutoPackage and why RPM is not the linux standard.
* Build packages that will install on many different distros
* Multiple front ends: best is automatically chosen so GUI users get a graphical front end, and command line users get a text based interface
* Multiple language support (both in tools and for your own packages)
* Automatically verifies and resolves dependencies no matter how the software was installed. This means you don't have to use Autopackage for all your software, or even any of it, for packages to successfully install.
# Is autopackage meant to replace RPM?
No. RPM is good at managing the core software of a distro. It's fast, well understood and supports features like prepatching of sources. What RPM is not good at is non-core packages, ie programs available from the net, from commercial vendors, magazine coverdisks and so on. This is the area that autopackage tackles. Although in theory it'd be possible to build a distro based around it, in reality such a solution would be very suboptimal as we sacrifice speed for flexibility and distro neutrality. For instance, it can take several seconds to verify the presence of all required dependencies, something that RPM can do far quicker.
# Why a new format? Why do the RPMs I find on the net today only work on one distro?
There are a number of reasons, some obvious, some not so obvious. Let's take them one at a time:
* Dependency metadata: RPMs can have several types of dependencies, the most common being file deps and package deps. In file deps, the package depends on some other package providing that file. Depending on /bin/bash for a shell script is easy, as that file is in the same location with the same name on all systems. Other dependencies are not so simple, there is no file that reliably expresses the dependency, or the file could be in multiple locations. That means sometimes package dependencies are preferred. Unfortunately, there is no standard for naming packages, and distros give them different names, as well as splitting them into different sized pieces. Because of that, often dependency information has to be expressed in a distro-dependent way.
* RPM features: because RPM is, at the end of the day, a tool to help distro makers, they sometimes add new macros and features to it and then use them in their specfiles. People want proper integration of course, so they use Mandrake specific macros or whatever, and then that RPM won't work properly on other distros.
* Binary portability: This one affects all binary packaging systems. A more detailed explanation of the problems faced can be found in Chapter 7 of the developer guide.
* Bad interactions with source code: because the current versions of RPM don't check the system directly, they only check a database, it makes it hard to install them on distros like Gentoo even when they only use file deps. Similar problems arise if you compile things from source.
There are various reasons why a new format was created rather than changing RPM. The first is that in order to do dependency checking in a distribution neutral fashion, a completely new dependency model was required. RPM expresses dependencies only in terms of other RPMs (and the same is true of all current package managers). An expressed dependency is usually given by a name or file location, but both of these things vary - usually pointlessly - between distributions. Worse, a dependency does not encode any information on where to find it or how to install it if it's missing: to get these features databases with all possible package names must be provided externally. If a name is found in a package but not a database you get the familiar "E: Broken Packages" error from apt. It is said that the package universe lacks closure. But, this is a natural and common occurance that any robust installer should be able to deal with cleanly.
Another reason was that when autopackage was designed, distributions and desktops differed greatly in how they dealt with things like menus and file assocations. It's been three years now, and this is still the case. While the situation is looking up, and we should soon have robust and well designed standards for these facilities, it will be years until they have been fully rolled out. Also there are still many things that are not yet standardised, like init scripts, documentation/help systems and so on.
To deal with this, it was felt that an API based approach rather than a table based approach was the way forward. New APIs could be added easily to deal with the case of things like installing a menu item which can be highly complex. Quirks in the distributions could be easily dealt with as the full power of bash scripting was available at every stage, so decisions like "should this file be installed here or here" can be answered on the fly.
Finally, there was a psychological reason. While RPMs can theoretica
|
|
pyrates wrote on the 28 Apr 08 at 08:11
|
Finally, there was a psychological reason. While RPMs can theoretically be multi-distro, in practice they never are. In practice, people do not know how to build multi-distro RPMs so on virtually all open source project websites you have different RPMs for different versions of each distribution. Worse, much software is not designed with binary portability in mind. Features are enabled/disabled at compile time instead of runtime, paths are hard coded into the binaries.
Creating a totally new format forces people to learn about it from us, and along the way we can teach them how to build robust and portable binaries using the tools we have produced, like apbuild which deals with the baroque glibc/gcc combination, relaytool which makes it trivial to adapt to missing libraries/library features at runtime, and binreloc which lets you easily make a typical autotools based project binary relocatable (installable to any prefix) at runtime. By using a new format, we ram home the point that this is different to what has come before, and requires modifications to the source, so making autopackages even more reliable and useful.
|
|
vexorian wrote on the 28 Apr 08 at 12:03
| |
So, I read the brainstorm, and I still have no idea why this would be good to do, can anyone elaborate on the why?
|
|
steve196 wrote on the 28 Apr 08 at 13:45
| |
Binaries in a tar.gz . Well written non-core apps should be installable by just unpacking their files into some directory in /home.
|
|
Jan-Nik wrote on the 1 Jun 08 at 12:15
|
@steve196
lzma would be better. Also extracting a tar.gz file does not create a menu entry. And what about dependency checking?
|
|
pyrates wrote on the 12 Oct 08 at 04:40
|
@Jan-Nik
AutoPackage creates the menu entries and checks if all the dependencies are there. The only bad part about it is that it all has to be in one big file, it can't reference other files that are in the same directory or a directory below the current one.
IE you run setup.bin and it uses the files in install1.tar.gz, install2.tar.gz, and install3.tar.gz to install the application checking if the necessary libraries are there.
|
Post your comment
|
