[pacman-dev] pacman port to BSD

[Antonio Huete Jimenez]

Dan McGee wrote:
> On Sun, Jun 1, 2008 at 6:22 AM, Sebastian Nowicki <sebnow at gmail.com> wrote:
>   
>> On 01/06/2008, at 5:30 PM, Antonio Huete Jimenez wrote:
>>
>>     
>>> Yes, I'm using ABS tree but not packages. What ABS tree should I use
>>> then? I obviously was trying to recompile everything using makeworld
>>> script but I got a --mtune gcc error that I need to solve just before
>>> compiling world again.
>>>       
>> You'd probably have to modify some of the packages, at least to remove
>> glibc (I'm not sure what BSD uses instead)
>>
>>     
>>> A thing I think I should add to makepkg/pacman is a way to handle
>>> world
>>> tools in the BSD userland. I mean, there are a lot of programs that
>>> are
>>> part of BSD world that pacman and its utilities should count with in
>>> order to not overlap them.
>>>       
>> What do you mean? I wouldn't use pkg_add, etc if I was using pacman.
>> That's just a recipe for disaster. Stick to one package management
>> system and everything should be ok.
>>     
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 :)
>>     
>>> Error over here is more like "don't know how to make pacman.8"
>>>
>>> Making all in doc
>>> make: don't know how to make pacman.8. Stop
>>> *** Error code 1
>>>
>>> Stop in /repos/work/pacman.
>>> *** Error code 1
>>>
>>>       
>> You need to specify --enable-asciidoc and/or --enable-doxygen for ./
>> configure. I don't know why the pacman PKGBUILD doesn't have either,
>> and yet somehow the man pages are there.
>>     
>
> This is so developers or downstream packagers are not required to have
> asciidoc installed when building pacman. In order to make a tarball,
> you must not be using --disable-doc, so the tarballs actualy come with
> the generated manpages. See commit 26c05b1c8c6fe639cd4.
>
> -Dan
>
> _______________________________________________
> pacman-dev mailing list
> pacman-dev at archlinux.org
> http://archlinux.org/mailman/listinfo/pacman-dev
>