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

Port of dpkg to NEXTSTEP


I've finally got the dpkg- suite compiling and working with NEXTSTEP,  
at least sufficient parts to start using it. Now I'd like to augment the suite  
with a few features to better support NEXTSTEP goodies, and I'd like to hear  
if similar thinks already have been discussed.

A short introduction to the situation with NEXTSTEP:

The NEXTSTEP OS runs on four architectures (m68k, i386, sparc and hppa).  
Cross-compiling is supported transparently on all archs, and executables,  
object files and libraries can be built FAT, i.e. one file contains multiple  
architectures. For executables, at load time only the necessary architectures  
segment is then loaded into memory (Mach-O object format). There are tools to  
remove, extract and add architectures from files.

It is a common practice to distribute packages quad-FAT. When unpacking and  
installing a NEXTSTEP pkg, you can choose which architectures should be  
installed, and which should be stripped.

While the NEXTSTEP concept of pkg's is nice for commercial tools and NEXTSTEP  
applications, it's no big help for classic Unix packages, esp. if you may  
want to update them later on.

This is where I'd like to establish dpkg and the deb format.

As I said, I have dpkg up'n'working for NEXTSTEP. But: How does a foreign  
operating system fit into deb's format ?

a) First of all, I'd like to have a way to distinguish Linux i386 deb  
packages from NEXTSTEP i386 deb packages, but I don't see yet an operating  
system field in deb.

b) Adding to that, it would be fine if there was a better granularity in  
specifying the included architectures, somewhat in between i386 and all, i.e.  
a way to specify that the package includes file that work on exactly the  
{m68k,i386} architectures (but no sparc, hppa).

c) Finally, it would be fine if the NEXTSTEP version of the dpkg tools would  
support "stripping" uneccessary archs at installation time. [Since no other OS  
(MacOS?) seems to handle MAB as transparent as NEXTSTEP does, this is  
certainly a very specific feature that needn't be discussed here.]

I'm most interested in reactions to a). Have there already been discussions  
about extending the deb format for operating systems other than Linux ? It  
probably would be possible just to establish an other extension for NEXTSTEP  
packages, e.g. .dnx instead of .deb, I don't know if that's the best solution.


| Gregor Hoffleit                        Mathematisches Institut, Uni HD |
| flight@mathi.uni-heidelberg.de      INF 288, 69120 Heidelberg, Germany |
| (NeXTmail, MIME)                      (49)6221 54-5771    fax  54-8312 |
| PGP Key fingerprint = 23 8F B3 38 A3 39 A6 01  5B 99 91 D6 F2 AC CD C7 |

Reply to: