[pacman-dev] pacman port to BSD

Sebastian Nowicki sebnow at gmail.com
Sun Jun 1 14:00:25 EDT 2008

On 02/06/2008, at 12:50 AM, Antonio Huete Jimenez wrote:

> Please, correct me if I'm wrong.
> As far as I know, all BSD derived distributions are delivered with the
> bare kernel and a set of userland software that might be or not BSD
> licensed. Thus, a lot of programs like top, patch,  cut, dc ... and a
> long etcetera are included, as well as a good amount of contrib  
> software
> just like binutils, gcc, gdb, less, file, tcsh, ... and all of this is
> available out-of-the box. Well, what I actually meant is that pacman
> should count with them and handle them as installed dependencies. Or  
> at
> least that would be the "correct" behaviour.
> Obviously, in the case that pacman was fully operative in a BSD  
> system,
> it must be the only package manager installed on the system, or the
> system could be easily trashed.
> For handling that glibc dependency, more on the same. BSDs have a
> standard libc available in their base, so a solution could be a  
> standard
> virtual package for BSD systems that could override that glibc
> dependency without having to change all tree dependencies in every  
> package.
> You know, going towards one only package system for every Unix like
> system is a nice goal to achieve :)

I can't really think of a clean way of doing this. If it's possible to  
do so, it's best to install as least as possible and install pacman as  
soon as possible, then use pacman to install the system. Otherwise you  
could make the packages of the utilities installed on BSD systems by  
default, and install them. Of course you will get file conflicts, so  
you'd have to force the installation (or remove the package using the  
native package manager). Pacman itself has nothing to do with this,  
it's the packages. As a hack you could also spoof the packages by  
creating database entries manually. You'd just have to find the list  
of files and write up a file with some metadata, then add it to the  
local database. You might even be able to use repacman or bacman to  
create a package from that :P.

I'm trying to create a repository for Mac OSX, and it's not going  
well. Initially I thought I'd just make the packages and force  
install, but of course Mac OSX doesn't have vanilla utilities so I'd  
have to use the one's they supply. Given that they only release  
versions of the utilities with each new OSX release, having a package  
for it is kind of pointless - they can't be updated, and removing them  
may break other things. Now I just made a dummy package with a list of  
all the utilities they provide in provides=(), eg. provides=('glibc'  
'vim' 'bash'). It's not an ideal solution, but it's quick and works. I  
can't install/upgrade/remove the utilities, but pacman knows that they  
are installed and I can depend on them. In the future I could also  
make actual packages for those utilities, and I wouldn't have to edit  
the depending PKGBUILDs due to how provides are handled (virtual  

Of course, you could always create "ArchBSD" and use pacman from the  
start ;).

More information about the pacman-dev mailing list