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."
Description: Binary data
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.