FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor


 
 
LinkBack Thread Tools
 
Old 05-29-2008, 10:38 PM
"Dan McGee"
 
Default pacman port to BSD

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

_______________________________________________
pacman-dev mailing list
pacman-dev@archlinux.org
http://archlinux.org/mailman/listinfo/pacman-dev
 
Old 05-30-2008, 05:39 AM
Sebastian Nowicki
 
Default pacman port to BSD

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
 
Old 05-31-2008, 09:42 AM
Antonio Huete Jimenez
 
Default pacman port to BSD

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

_______________________________________________
pacman-dev mailing list
pacman-dev@archlinux.org
http://archlinux.org/mailman/listinfo/pacman-dev
 
Old 05-31-2008, 11:25 AM
Sebastian Nowicki
 
Default pacman port to BSD

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


_______________________________________________
pacman-dev mailing list
pacman-dev@archlinux.org
http://archlinux.org/mailman/listinfo/pacman-dev
 
Old 06-01-2008, 09:30 AM
Antonio Huete Jimenez
 
Default pacman port to BSD

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
>


_______________________________________________
pacman-dev mailing list
pacman-dev@archlinux.org
http://archlinux.org/mailman/listinfo/pacman-dev
 
Old 06-01-2008, 11:22 AM
Sebastian Nowicki
 
Default pacman port to BSD

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.


_______________________________________________
pacman-dev mailing list
pacman-dev@archlinux.org
http://archlinux.org/mailman/listinfo/pacman-dev
 
Old 06-01-2008, 02:53 PM
"Dan McGee"
 
Default pacman port to BSD

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

_______________________________________________
pacman-dev mailing list
pacman-dev@archlinux.org
http://archlinux.org/mailman/listinfo/pacman-dev
 
Old 06-01-2008, 04:50 PM
Antonio Huete Jimenez
 
Default pacman port to BSD

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
>


_______________________________________________
pacman-dev mailing list
pacman-dev@archlinux.org
http://archlinux.org/mailman/listinfo/pacman-dev
 
Old 06-01-2008, 06:00 PM
Sebastian Nowicki
 
Default pacman port to BSD

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 .

_______________________________________________
pacman-dev mailing list
pacman-dev@archlinux.org
http://archlinux.org/mailman/listinfo/pacman-dev
 

Thread Tools




All times are GMT. The time now is 07:39 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org