[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

dpkg for FreeBSD



Yesterday I experimented with dpkg on FreeBSD and I've ported
dpkg to FreeBSD.

Please, note, I'm telling about porting a _program_, not _whole distribution_.

RPM is ported to many systems, even commercial Solaris, etc.
dpkg is still too Debian specific. I think it is wrong because I know
people who use RPM on many different OS-es, but dpkg can be used
only on Linux system (or GNU/HURD).

My laboratory:

* FreeBSD-3.3
* autoconf/automake
* bash as /bin/sh
* gmake as /usr/bin/make (but it is no good!)
* libgnugetopt

My report:

* dpkg detects an architecture by executing 'gcc -print-libgcc-file-name'.
  This is wrong on FreeBSD, because this file is simply /usr/lib/libgcc.a
  I suggest if this check is failed, dpkg should have a reasonable default
  value. This value could be set by ./configure --with-default-arch=XXX.
  I've done workaround in dpkg-gencontrol, etc. scripts but modifing
  dpkg binary is necessary.

* I had to add some new options to configure.in, but it worked. This was
  ptrdiff_t for enquiry.c and 
  
* On FreeBSD some includes and libraries are located at /usr/include tree. 
  I've adaptaded Makefile manually. Is it possible to do autodetection?
  I guess autoconf can do it but I know this tool a little.
  
* How to detect an current OS from compilator? #ifdef linux and #ifdef __GNU__
  worked for linux and hurd, but I didn't know how to detect FreeBSD.
  I think it could be exported from ./configure detection, not hardcoded
  in this way.
  
* start-stop-daemon is too OS specific so I don't know if it works on FreeBSD.
  Maybe some BSD-guru could port this tool?
  
* dselect didn't compile at all. I can live without it but I'd like to
  have ./configure --without-dselect option.
  
* I had to compile dpkg twice time. First: "make; make install", second:
  "debian/rules binary". But these methods generated completly different code!
  I.e. "make" generated ADMINDIR="/usr/var/dpkg" (!??).
  
* "make install" didn't create /var/lib/dpkg/{status|availables} empty files,
  so I had to create them manually. Really, I had to create them twice,
  in /usr/var/dpkg and /var/lib/dpkg directories.. (?)
  
* debian/rules file uses /usr/bin/make program. This is correct if make
  is GNU make! I suggest the rules file should use i.e. /usr/bin/dpkg-make
  which is a symlink to real GNU make (at FreeBSD this is /usr/local/bin/gmake).
  
* Similar problem with /bin/sh which wasn't compatible with bash. I replaced
  /bin/sh by /usr/local/bin/bash. I'm afraid dpkg scripts use bashizm.
  
* In FreeBSD the "mv" doesn't have '-v' option and "xargs" doesn't have
  '-r0' option. I had to modified debian/rules.

* I was suprised that after "debian/rules binary" I've lost some files
  from debian/ directory, i.e. debian/dev-* scripts.
  
* After touching /var/lib/dpkg/status and /usr/var/dpkg/status 
  I could run "dpkg -i dpkg_*.deb" :-) Then dpkg told me 
  (probably postinst script) I hadn't /etc/rc0.d directory. Damn, right!
  This is FreeBSD and there is no /etc/rc0.d directory ;-)
  
* Well done. "dpkg --list" told me I had dpkg package installed. It was
  exciting four hours.
  

Why did I ported dpkg on BSD-like system? It was an experiment, but I think
dpkg could be useful on non-Linux platforms. I hope the dpkg became 
universal package manager which isn't specific for one system.

I could attach my patch if you are interested in. It can be probably
included to official version, but it required some modification in
current version which I can't do:

* default architecture or workaround for "gcc -print-libgcc-file-name"
* ./configure --without-dselect
* detecting of architecture in C code (#ifdef <architecure>)
* start-stop-daemon ported to FreeBSD.
* "#!/usr/bin/dpkg-make -f" in debian/rules ?? Maybe 
  "./configure --with-gnu-make=/usr/local/bin/gmake" ?
  

I think it could be possible to port dpkg on win32 platform with cygwin
library, but Solaris could be another step.
  
-- 

Piotr "Dexter" Roszatycki
mailto:dexter@fnet.pl


Reply to: