Hello. These are my set of patches to make apt and dpkg compile on FreeBSD 4.2. The versions I used are rather old, but.. these were the first I've found. For dpkg archive contains a full FreeBSD-compatible port, which is ready for installing. You can even install packages with it ;-), but ignoring dependecies, of course :) Apt archive is just a set of patches that I've made to make apt compile. It does not contain any Makefile and other stuff to make it a full port. And the last thing: I didn't tried getting something with it. Please, try and share the experience :) Finally, README file contains some notes about the patches I've made and the reasons for them -- worth reading :) And now, my thoughts (hope it won't take too much time :) During last few months I've been using FreeBSD and OpenBSD rather heavily as a platform for development and as a servers -- and I have figured out one thing. All BSD's right now do have the "user environment", which has been established during years of their existence, and I've found (once I get used to it, finally :) that there is no need to create something new. Everything there is polished and works already, just like BSD users would want it to be. In my mind, Linux users (at least, most of them) would not go on the other OS (or kernel) -- just because of the same situation, they have everything working just like they want. So, I see no need in the project of creating the whole new Debian with a BSD kernel. But! Definately (and most BSD users would agree with me), these OSes have a _very_,_very_,_very_ inconvinient way of managing packages (that has been formed since the time sysadmins compiled everything on their machines, which is the right way, but not for end-users :), and the presense of the apt and dpkg on these platforms, with the bunch of prepackaged software would help alot. Openpackages is the similar effort, but as I see, they didn't made a big progress yet (if I am wrong, forget it :), while Debian's package management tools have gone a long way. So, as a short summary, I see no need in making BSDs SysV-compatible, porting glibc, making ext2fs the default (crazy idea :), and so on. What is needed is a good package management -- and I promise you, you'll like BSD in it's current state :) IMPORTANT NOTE: The things that I've written should NOT be treated as a propaganda against debian-bsd. If you guys would do something, I'll be happy, and would even help you within my abilities :) P.S. By the way, in my mind, this is the first code sent to the list, so everybody say "Ho!", and get some beer :) -- Regards, Wartan. "Computers are not intelligent. They only think they are."
Attachment:
apt-patches.tar.gz
Description: Binary data
Attachment:
dpkg-port.tar.gz
Description: Binary data
First of all, I would really like to say that I'm in no way a specialist.
So, if I've done something wrong (and I did :), don't blame me.
-- dpkg-1.7.2
1. Problems arised with start-stop-daemon. __FreeBSD__ wasn't listed in the
check for supported architectures, and compile failed.
Second problem was with functions checking several attributes of processes
in /proc (pid_is_exec, pid_is_cmd). That was heavy os-dependent, and the
code seemed to do nothing when faced an unkown architecture -- so
all those functions just do a return right now of FreeBSD.
It would be great if someone with a deeper knowledge of the FreeBSD
/proc would check them.
Also, there was a little problem with setpgrp that is just synonym
for setpgid(0,0) on glibc.
2. It seems that if libintl is not found in the system, dpkg tries to
use the one included with the distro. But in one case -- with
md5.c that doesn't work -- seem like someone just forgot to do a
-lintl in the compile directive. I did patched Makefile.
Actually, this is not the way to go, because when I told it to
compile with -lintl, gcc used gettext installed on the system, but
headers have been used from included libintl. Maybe, we should
remove the included libintl, and get it to configure with
system-installed one.
3. Documentation in DebianDoc isn't installed because there is no
converter ported right now. We have to port debiandoc package.
4. I did added i386-freebsd4.2 in the archtable, since this is the
architecture detected by configure.
Anyway, dpkg --print-architecutre returns:
dpkg: unexpected output from `gcc --print-libgcc-file-name':
`/usr/lib/libgcc.a'
dpkg: compiler libgcc filename not understood: no gcc-lib component
Our FreeBSD gcc's libgcc lives in /usr/lib/, which totally confuses
all the dpkg's and apt's way of detecting the architecture.
(which is done by parsing this the output of the above command, and
on Linux it looks like '/usr/lib/gcc-lib/i486-linux/2.7.2/libgcc.a')
We've got two ways -- either repackage gcc, or change dpkg and apt.
ALSO: I've patched config.guess script from dpkg distribution to
behave just like the one from apt, since it
determines the host_os by also checking /usr/bin/objformat on FreeBSD,
and thus making my 4.2 to be freebsdelf4.2, which is the Right Thing
(IMO) (and also that leads to the unified host_os guessing in both packages)
[Yes, yes, I know where to find latest master version of this file.
Now this is just a quick hack.]
-- apt-0.3.19
1. Autoconf's configure.in contained "make dirs" in AC_OUTPUT. Of
course, that caused errors, because make in this world means BSD
make ;), so I've changed it onto gmake.
2. Apt writers made some wrapper class around mmap (apt-pkg/contrib/mmap.cc)
to make it work on a broken glibc. On FreeBSD the code doesn't
work without including types.h (Well, huh. I wonder if it works
on Linux.. Never mind. There I use Debian binaries :)
3. A bit stuck with pthreads. Wrapper class for errors
(apt-pkg/contrib/error.cc) has two cases -- if the system supports
pthreads, thread-safe version is used, if not than non-safe.
First of all, g++ refused to compile the directive
#if _POSIX_THREADS == 1
with syntax error. Very strange. Ok, I've left only
#if defined(HAS_PTHREADS)
and that fails, so non-safe version is used.
The problem is that FreeBSD doesn't have libpthreads, and threaded
programs are linked against libc_r with the gcc option -pthreads.
Now configure doesn't find the library, and think that pthreads are
not supported.
I'll have a look on how the other freebsd'ers solve it..
4. Apt produces static libraries, because it doesn't know how to make
them on other archs than linux-gnu. The funny thing is that on
FreeBSD they are produced just the same way. So I had to change
environment.mak.in script to pass the SONAME check on
freebsdelf4.2.