Changes between Version 1 and Version 2 of Obsolete/MovedToTree/PackageManagement/OldIdeas


Ignore:
Timestamp:
Aug 4, 2009 5:08:13 PM (10 years ago)
Author:
Blub
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • Obsolete/MovedToTree/PackageManagement/OldIdeas

    v1 v2  
    1 This page is a place to hash out ideas regarding Haiku's package management.
     1= Package Management Ideas =
     2This page is a place to hash out ideas regarding Haiku's package management (and creation).
     3
     4== libalpm ==
     5(and it's tool: pacman)
     6
     7libalpm is the package management library used on ArchLinux, most people know it as "pacman" since that's the main tool to use, however, all the functionality is part of the libalpm library which could be utilized to create a nice GUI frontend for the package manager.
     8It of course can also be adapted.
     9
     10It uses libarchive to extract archives, and either libdownload or libfetch to download files - although one can also have it use an external command, like curl or wget.[[BR]]
     11The current status is this:[[BR]]
     12As far as libfetch is concerned: compiles and is linked to, but it doesn't really work, so I'm using curl instead - it works like a charm.[[BR]]
     13The important part: libarchive needed some work to support zip files in a useful way. Basically, it now supports seeking (which it didn't before), the central-directory headers for ZIP files (so it supports stuff like symlinks), and BeOS file attributes! Also, when reading from a source which doesn't allow seeking (... which are... none - on our case) it simply reads the local headers, but can also - if explicitly requested - provide "update"-entries to update the raw data when the central directory is reached (but those are of no importance anymore).
     14
     15What's good about libalpm? Well, it provides useful configuring mechanisms, it stores dependencies and can also give you a list of which packages require a certain package. It keeps a database containing package information, including a file list. Configuration files in packages can be listed as such, which causes them to be installed as *.pacnew when they are upgraded (unless the new and old files equal - an md5 sum check is used there.)
     16It provides the ability to use different database directories which allows us to have an automated way of creating package bundles.
     17For instance, I can set the installdir to /tmp/mypackage and install the game "einstein" including its dependencies there, then move /tmp/mypackage/einstein/common/lib to /tmp/mypackage/einstein/lib, remove the unnecessary manpages, share files (well, usually anything else which is in the common/ folder), and then strip those dependencies from einstein's .PKGINFO file and create a bundled package which I can then install normally to say /boot/apps.
     18
     19Another useful feature is the possibility to change the root directory. When a package contains a .INSTALL script, libalpm chroot()s into the root directory,
     20cd()s into the installation directory, and then executes the .INSTALL script (which means, that install-scripts can and should work relative to the installation directory, although, if necessary, the absolute path is available in $PWD)
     21
     22Also, libalpm works similar to an actual database. It doesn't blindly attempt to install a package, but first check for file conflicts, see if any files need backups or configuration files need to be installed as .pacnew, and then installs a package. If you install multiple packages at once, then it only either installs all of them, or none.
     23It allows you to find the owning package of a file in the filesystem as well as listing all the files and dependencies of a package.
     24
     25Where does it get the packages form?
     26Two possibilities: One can use package files directly - which could be made in such a way that you could also just unzip them. In fact, it might be useful to put the .PKGINFO into the zip file as some extra data which is not unzipped when simply using `unzip´, although package creation is easier if it's just a file.
     27The other one being repositories. The pacman utility currently allows you to list repositories like this in pacman.conf:
     28{{{
     29[core]
     30Server = file:///MyRepositories
     31
     32[devel]
     33Server = file:///MyRepositories
     34
     35[public]
     36Server = http://www.public-repository.com/
     37}}}
     38When you synchronize the repository databases, pacman downloads the file <Server>/<Reponame>.db.tar.gz which contains a list of packages with dependencies.
     39When you install a package from such a repository, it downloads them from the very same location: <Server>/<Package File>
     40The repo.db.tar.gz files are currently created using the tools `repo-add` and `repo-remove` provided in the pacman package. Those extract information from the .PKGINFO file and put it into the database which can be used as a repository then.
     41
     42Here's a little log of using pacman to install a package file, and bundle a package with dependencies together into one package file.
     43http://stud4.tuwien.ac.at/~e0725517/using-pacman-on-haiku.log.txt
     44
     45=== Pros ===
     46 * It has been used on archlinux for a long time - so it works.
     47 * It's obviously possibly to compile and use it on haiku
     48 * Since most of its functionality is part of a library, it can be reused to build a GUI-application utilizing libalpm
     49 * pacman also provides scripts for building packages using a PKGBUILD script.
     50
     51=== Cons ===
     52 * Your turn :P
     53 * (It's not BePorter, but hey, it might be possible to use them together: BePorter to create packages and bundles, and libalpm for managing the installed packages.)