Gast
2004-07-04, 00:58:26
# What is autopackage?
autopackage is software that lets you create binary packages for Linux that will install on any distribution, can be interactive, can automatically resolve dependencies and can be installed using multiple front ends, for instance from the command line or from a graphical interface.
# What does this offer me that RPM/DPKG doesn't?
The RPM Package Manager was originally created by Red Hat to solve a problem that they had - namely, how to manage the software that they had packaged for their distribution. As Red Hat became dominant, people began creating RPMs and putting them on the internet, and other distributions adapted RPM to their own needs. The problem is, RPM was never designed to work on multiple types of distro, it is essentially designed to aid in the building of a distribution.
DPKG is the Debian package manager. It too was designed with a single distribution in mind. Although Debian became famous for having easy package management, this is mostly due to the very large repositories it has. The chances are good that the software you want is available, though not necessarily always in the latest version.
The system of attempting to package everything the user of the distro might ever want is not particularly scalable or easily adapted to other platforms. Although apt-rpm exists, it doesn't solve the problem that RPMs are specific to a distribution. By not scalable, I'm referring to 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. This makes as little sense as centralising the writing of documentation, or the design of user interfaces. Hence, autopackage tries to be decentralised.
In short, if you create an autopackage, it will be able to install on any reasonably standard distribution, which lets us all concentrate on writing amazing free software, instead of building and rebuilding packages :)
Autopackage also differs in its approach to dependency management: rather than maintaining a huge database of files which will inevitably get out of date the moment you install from the source or copy files from another computer, autopackage directly checks the system itself for the stuff it needs.
# 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 stuff like prepatching of sources. What RPMs tend not to be good at is non-distro supplied packages, ie programs available from the net, from extra CDs 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 somewhat 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. One day we may optimize autopackage sufficiently that it's possible to use it for managing a complete distro as well, but that isn't a priority.
http://autopackage.org/faq.html
I would like to see inter-distribution binary compatibility for KDE apps. This means that KDE recommends a set of compiler, library versions, compilation flags etc that has to be used for building KDE. Then you could have compile-once-run-everywhere KDE binaries and make the life for 3rd party developers much easier, together with Autopackage or a similar tool that should be finished when KDE4 is out and could be embraced by KDE
http://www.kdedevelopers.org/node/view/172
autopackage is software that lets you create binary packages for Linux that will install on any distribution, can be interactive, can automatically resolve dependencies and can be installed using multiple front ends, for instance from the command line or from a graphical interface.
# What does this offer me that RPM/DPKG doesn't?
The RPM Package Manager was originally created by Red Hat to solve a problem that they had - namely, how to manage the software that they had packaged for their distribution. As Red Hat became dominant, people began creating RPMs and putting them on the internet, and other distributions adapted RPM to their own needs. The problem is, RPM was never designed to work on multiple types of distro, it is essentially designed to aid in the building of a distribution.
DPKG is the Debian package manager. It too was designed with a single distribution in mind. Although Debian became famous for having easy package management, this is mostly due to the very large repositories it has. The chances are good that the software you want is available, though not necessarily always in the latest version.
The system of attempting to package everything the user of the distro might ever want is not particularly scalable or easily adapted to other platforms. Although apt-rpm exists, it doesn't solve the problem that RPMs are specific to a distribution. By not scalable, I'm referring to 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. This makes as little sense as centralising the writing of documentation, or the design of user interfaces. Hence, autopackage tries to be decentralised.
In short, if you create an autopackage, it will be able to install on any reasonably standard distribution, which lets us all concentrate on writing amazing free software, instead of building and rebuilding packages :)
Autopackage also differs in its approach to dependency management: rather than maintaining a huge database of files which will inevitably get out of date the moment you install from the source or copy files from another computer, autopackage directly checks the system itself for the stuff it needs.
# 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 stuff like prepatching of sources. What RPMs tend not to be good at is non-distro supplied packages, ie programs available from the net, from extra CDs 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 somewhat 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. One day we may optimize autopackage sufficiently that it's possible to use it for managing a complete distro as well, but that isn't a priority.
http://autopackage.org/faq.html
I would like to see inter-distribution binary compatibility for KDE apps. This means that KDE recommends a set of compiler, library versions, compilation flags etc that has to be used for building KDE. Then you could have compile-once-run-everywhere KDE binaries and make the life for 3rd party developers much easier, together with Autopackage or a similar tool that should be finished when KDE4 is out and could be embraced by KDE
http://www.kdedevelopers.org/node/view/172