[pacman-dev] pacman port to BSD
Hello I would like to know if there is some work in progress to porting pacman to any BSD system Cheers, Antonio Huete
On Thu, May 29, 2008 at 5:07 PM, Antonio Huete Jimenez <ahuete.devel@gmail.com> wrote:
Hello
I would like to know if there is some work in progress to porting pacman to any BSD system
You may want to take a look at the archives for this month: http://archlinux.org/pipermail/pacman-dev/2008-May/thread.html Many of the posts from Sebastian Nowicki are related to getting makepkg to work on Mac OSX which is obviously similar to BSD. http://archlinux.org/pipermail/pacman-dev/2008-May/011830.html http://archlinux.org/pipermail/pacman-dev/2008-May/011837.html In addition, libalpm & pacman should be fully buildable and testable on BSDs and OSX. libfetch will be used in place of libdownload, and libarchive must be available as well. We did a lot of work last October to get it compiling on FreeBSD. This is all available in the pacman git repository. With that said, none of us main developers use BSD as a primary or even secondary system, so it doesn't get much testing. We would need help from someone in those communities to help out and ensure we remain compatible. -Dan
On 30/05/2008, at 6:38 AM, Dan McGee wrote:
On Thu, May 29, 2008 at 5:07 PM, Antonio Huete Jimenez <ahuete.devel@gmail.com> wrote:
Hello
I would like to know if there is some work in progress to porting pacman to any BSD system
You may want to take a look at the archives for this month: http://archlinux.org/pipermail/pacman-dev/2008-May/thread.html
Many of the posts from Sebastian Nowicki are related to getting makepkg to work on Mac OSX which is obviously similar to BSD. http://archlinux.org/pipermail/pacman-dev/2008-May/011830.html http://archlinux.org/pipermail/pacman-dev/2008-May/011837.html
In addition, libalpm & pacman should be fully buildable and testable on BSDs and OSX. libfetch will be used in place of libdownload, and libarchive must be available as well. We did a lot of work last October to get it compiling on FreeBSD. This is all available in the pacman git repository.
With that said, none of us main developers use BSD as a primary or even secondary system, so it doesn't get much testing. We would need help from someone in those communities to help out and ensure we remain compatible.
I have been using pacman on Mac OSX for about a month now, and it's working great. As far as I can tell there's nothing wrong with it on BSD. As I said in another mail, there are still some problems with the dev toolset (makepkg, repo-add, etc), but makepkg is getting there, it's definitely useable. I haven't tested pacman on FreeBSD or any other BSD, but I don't see why it wouldn't work there as well. -- Sebastian Nowicki
Sebastian Nowicki wrote:
On 30/05/2008, at 6:38 AM, Dan McGee wrote:
On Thu, May 29, 2008 at 5:07 PM, Antonio Huete Jimenez <ahuete.devel@gmail.com> wrote:
Hello
I would like to know if there is some work in progress to porting pacman to any BSD system
You may want to take a look at the archives for this month: http://archlinux.org/pipermail/pacman-dev/2008-May/thread.html
Many of the posts from Sebastian Nowicki are related to getting makepkg to work on Mac OSX which is obviously similar to BSD. http://archlinux.org/pipermail/pacman-dev/2008-May/011830.html http://archlinux.org/pipermail/pacman-dev/2008-May/011837.html
In addition, libalpm & pacman should be fully buildable and testable on BSDs and OSX. libfetch will be used in place of libdownload, and libarchive must be available as well. We did a lot of work last October to get it compiling on FreeBSD. This is all available in the pacman git repository.
With that said, none of us main developers use BSD as a primary or even secondary system, so it doesn't get much testing. We would need help from someone in those communities to help out and ensure we remain compatible.
I have been using pacman on Mac OSX for about a month now, and it's working great. As far as I can tell there's nothing wrong with it on BSD. As I said in another mail, there are still some problems with the dev toolset (makepkg, repo-add, etc), but makepkg is getting there, it's definitely useable. I haven't tested pacman on FreeBSD or any other BSD, but I don't see why it wouldn't work there as well.
-- Sebastian Nowicki
_______________________________________________ pacman-dev mailing list pacman-dev@archlinux.org http://archlinux.org/mailman/listinfo/pacman-dev
Hello I've just compiled and tested pacman with some minor make problems (like being unable to compile pacman.8) under DragonFlyBSD. pacman seems to run fine, but I've been unable to make packages using makepkg, due a fail when parsing opts and due that glibc dependency on every package you need to build. I think there was some patch on pacman-dev to fix that problem with parsing opts to bash scripts, but what about glibc dependency on BSD systems? How can I avoid it? I'll provide detailed information when I have something useable. Regards & thanks for your help Antonio Huete
On 31/05/2008, at 5:42 PM, Antonio Huete Jimenez wrote:
Hello
I've just compiled and tested pacman with some minor make problems (like being unable to compile pacman.8) under DragonFlyBSD. pacman seems to run fine, but I've been unable to make packages using makepkg, due a fail when parsing opts and due that glibc dependency on every package you need to build. I think there was some patch on pacman-dev to fix that problem with parsing opts to bash scripts, but what about glibc dependency on BSD systems? How can I avoid it?
I'll provide detailed information when I have something useable.
Regards & thanks for your help Antonio Huete
_______________________________________________ pacman-dev mailing list pacman-dev@archlinux.org http://archlinux.org/mailman/listinfo/pacman-dev
Are you using Archlinux's ABS tree or packages? That probably won't work, you'll have to recompile everything, and of course that way you can remove the glibc dependency. As for argument parsing I'm not sure what the status of that is. I made a really bad patch that kinda works for most options, but I wouldn't recommend using that one. As far as I know Xavier is working on something. There seem to be some problems with readlink in the Makefile (or asciidoc, haven't really looked into it), which I'll have to tackle for repo-add as well. Luckily you can just --disable-doc and it will compile fine.
Making all in doc a2x -d manpage -f manpage --xsltproc-opts='-param man.endnotes.list.enabled 0' --xsltproc-opts='-param man.endnotes.are.numbered 0' --asciidoc-opts="-f asciidoc.conf -a pacman_version="3.2.0devel" -a pacman_date="`date +%Y-%m-%d`" -a sysconfdir=/etc" pacman.8.txt readlink: illegal option -- f usage: readlink [-n] [file ...] a2x: failed: enhanced getopt(1) required make[2]: *** [pacman.8] Error 1
-- Sebastian Nowicki
Sebastian Nowicki wrote:
On 31/05/2008, at 5:42 PM, Antonio Huete Jimenez wrote:
Hello
I've just compiled and tested pacman with some minor make problems (like being unable to compile pacman.8) under DragonFlyBSD. pacman seems to run fine, but I've been unable to make packages using makepkg, due a fail when parsing opts and due that glibc dependency on every package you need to build. I think there was some patch on pacman-dev to fix that problem with parsing opts to bash scripts, but what about glibc dependency on BSD systems? How can I avoid it?
I'll provide detailed information when I have something useable.
Regards & thanks for your help Antonio Huete
_______________________________________________ pacman-dev mailing list pacman-dev@archlinux.org http://archlinux.org/mailman/listinfo/pacman-dev
Are you using Archlinux's ABS tree or packages? That probably won't work, you'll have to recompile everything, and of course that way you can remove the glibc dependency. As for argument parsing I'm not sure what the status of that is. I made a really bad patch that kinda works for most options, but I wouldn't recommend using that one. As far as I know Xavier is working on something.
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. 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. About the getopt handling, I'll wait for Xavier since I don't have time to learn getopt magic :)
There seem to be some problems with readlink in the Makefile (or asciidoc, haven't really looked into it), which I'll have to tackle for repo-add as well. Luckily you can just --disable-doc and it will compile fine.
Making all in doc a2x -d manpage -f manpage --xsltproc-opts='-param man.endnotes.list.enabled 0' --xsltproc-opts='-param man.endnotes.are.numbered 0' --asciidoc-opts="-f asciidoc.conf -a pacman_version="3.2.0devel" -a pacman_date="`date +%Y-%m-%d`" -a sysconfdir=/etc" pacman.8.txt readlink: illegal option -- f usage: readlink [-n] [file ...] a2x: failed: enhanced getopt(1) required make[2]: *** [pacman.8] Error 1
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
-- Sebastian Nowicki
_______________________________________________ pacman-dev mailing list pacman-dev@archlinux.org http://archlinux.org/mailman/listinfo/pacman-dev
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.
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.
On Sun, Jun 1, 2008 at 6:22 AM, Sebastian Nowicki <sebnow@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.
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
Dan McGee wrote:
On Sun, Jun 1, 2008 at 6:22 AM, Sebastian Nowicki <sebnow@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@archlinux.org http://archlinux.org/mailman/listinfo/pacman-dev
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 packages). Of course, you could always create "ArchBSD" and use pacman from the start ;).
participants (3)
-
Antonio Huete Jimenez
-
Dan McGee
-
Sebastian Nowicki