Statically linked version of pacman

snack · 2011-12-30 09:33:22

Hi, I need some advice from pacman experts. At work I'm facing the problem of software distribution to my scientific collaboration, as a first step as precompiled binaries. This is much like what Archlinux does, so at first shot I had the idea to use pacman to distribute packages (and later maybe also abs, makepkg and other tools to distribute and compile sources). The first problem I'm facing is that my collaboration is rather heterogeneous so many Linux flavors are used, often also very old versions in production environments. To go on with my plan I need to have at least a pacman binary which could run almost on every system, so I was thinking about a statically linked version of pacman, with (almost) no dependencies on shared libraries. Is it feasible? Is it hard to implement? I looked at pacman's source but I'm not an expert of autotools configuration. So before spending my time in learning autotools I'd like an opinion from pacman experts about feasibility and pitfalls of this idea.
Many thanks.

Trilby · 2011-12-30 12:58:51

While I adore pacman on arch, I don't see it's usefulness for your situation.

What would be wrong with using some thing like dropbox, or git, etc to store the source code? Users could download source tarballs, and use the more universal

./configure
make
sudo make install

on any *nix system.
You could even make scripts for each piece of software following the logic of PKGBUILDS but not to make pacman-style packages, but rather to install directly. Essentially the script would just automate the download and compilation.

Trilby · 2011-12-30 12:59:41

I suppose in other words, I'm wondering what services of pacman you want available to them.

snack · 2011-12-30 13:32:42

Trilby wrote:

I suppose in other words, I'm wondering what services of pacman you want available to them.

I would like a toll to make it easy to install and upgrade software. One of the most difficult things with my colleagues is to make them install the bugfix releases of the codes we use (they typically install once and use forever...), a pacman -Syu would be an easy-enough solution
Moreover, pacman together with abs and makepkg is very flexible since it lets you install binaries or compile from source very easily once you have the PKGBUILDs, and I need the ability to compile from source since binaries may not work on all the machines I have to target.

Edit: I'm actually writing a script that automates download and installation, but relying on a true package manager plus having the whole set of Arch's PKGBUILDs available would make my life A LOT easier...

Last edited by snack (2011-12-30 13:39:15)

R00KIE · 2011-12-30 13:39:04

Mixing package managers in the same system doesn't sound like a good idea to me, maybe you should look into puppet or similar solutions and stick with each distro's package manager or alternatively copy the files manually to a _safe_ and _separate_ location in the filesystem.

snack · 2011-12-30 13:44:25

R00KIE wrote:

Mixing package managers in the same system doesn't sound like a good idea to me, maybe you should look into puppet or similar solutions and stick with each distro's package manager or alternatively copy the files manually to a _safe_ and _separate_ location in the filesystem.

My intention was to use pacman not "as is" but rather hack its configuration to make it use a custom folder for installation, so that all my packages would not be installed in /usr but rather in a custom folder, so that headers and binaries of my packages would not mix with the others.
I cannot stick with a single package manager since my colleagues use almost every available Linux distribution, ranging from Debian to Ubuntu to Scientific to openSUSE... the only way is to have a cross-distro tool, and a hack of pacman was the most appealing to me (I'm on Arch, in the end... )

Trilby · 2011-12-30 13:53:25

I'm far from an expert on such things, but perhaps rather than fiddling with pacman, perhaps you could just build your own.

It sounds like all you'd really need is a a tool (could be compiled, or just script) to translate PKGBUILDS and maintain a list of installed packages, On an update command, it would retrieve the most recent PKGBUILDS for the packages on it's list, check if they're new, and if they are it'd 'translate' the PKGBUILD instructions to install to your chosen location - most likely by changing srcdir.

Trilby · 2011-12-30 14:04:52

I suspect with this though you'd run into other problems. As arch is a rolling release and Ubuntu, for example, is not, when an update is available in the AUR it may have dependencies that would not be available in Ubuntu. This would require your Ubuntu users to install depencies from the AUR as well, and these dependencies would have their own dependencies and arch-specific patches, etc. Soon you'd just be making your Ubuntu users install all of arch (not a bad idea...).

I don't think you're going to be able to maintain your own sanity while trying to maintain bleeding-edge software versions on non-rolling release systems.

You may just have to get them all to use their own branches testing repos to get the newest versions of whatever software you need them to have.

Or you could just be content using an older version of the software until the release-based distros catch up.

snack · 2011-12-30 14:14:47

Trilby wrote:

I suspect with this though you'd run into other problems. As arch is a rolling release and Ubuntu, for example, is not, when an update is available in the AUR it may have dependencies that would not be available in Ubuntu. This would require your Ubuntu users to install depencies from the AUR as well, and these dependencies would have their own dependencies and arch-specific patches, etc. Soon you'd just be making your Ubuntu users install all of arch (not a bad idea...).
I don't think you're going to be able to maintain your own sanity while trying to maintain bleeding-edge software versions on non-rolling release systems.
You may just have to get them all to use their own branches testing repos to get the newest versions of whatever software you need them to have.
Or you could just be content using an older version of the software until the release-based distros catch up.

I'm not willing to set up a truly rolling release machinery. My plan was to have a stable repo where only bugfix updates would be pushed, so that upgrade would be very rare, and a testing repo to prepare the next big release. The whole thing would be completely disconnected from Arch repos and AUR, I would set up my own.

Xemertix · 2011-12-31 19:56:14

http://www.stanford.edu/~pgbovine/cde.html
http://portablelinuxapps.org/
etc...

Arch Linux

#1 2011-12-30 09:33:22

Statically linked version of pacman

#2 2011-12-30 12:58:51

Re: Statically linked version of pacman

#3 2011-12-30 12:59:41

Re: Statically linked version of pacman

#4 2011-12-30 13:32:42

Re: Statically linked version of pacman

#5 2011-12-30 13:39:04

Re: Statically linked version of pacman

#6 2011-12-30 13:44:25

Re: Statically linked version of pacman

#7 2011-12-30 13:53:25

Re: Statically linked version of pacman

#8 2011-12-30 14:04:52

Re: Statically linked version of pacman

#9 2011-12-30 14:14:47

Re: Statically linked version of pacman

#10 2011-12-31 19:56:14

Re: Statically linked version of pacman

Board footer