--- Jeremie Koenig <[EMAIL PROTECTED]> > But which of these are part of the "debian architecture" concept ? > Traditionnaly, it would be os and arch (as in hurd-i386 or bsd-i386). > Our situation is a bit more complicated since our runtimes sometimes > touch the "OS" area (this is especially true with DJGPP, which uses > other binary types, DPMI extending to run 32bit apps under DOS, ...). > > I really can't tell you my preference here, since it varies from day > to > day ;) > > As promised, the URL of marcus' blurb about architectures handling. > His > way may some day provide answers to our existential questions. (in > short: instead of having packages rely upon a debian architecture, > the > whole things could be handled by extending the dependency system and > dropping the architecture field of packages.) > > http://master.debian.org/~brinkmd/arch-handling.txt > > There was some discussion about this on [EMAIL PROTECTED] : > > http://lists.debian.org/debian-bsd/2002/debian-bsd-200202/msg00131.html >
I aggree that we need to start now with a re-specification of the dpkg system. Basically we need to: 1. Create a better way to share data between perl and C (and other langauges) Inline, Swig, IDL come to mind. 2. Create a way to store this package information in a database. 3. Create a way to download and install them. 4. Make all this backwards compatible to debian. mike ===== James Michael DuPont http://introspector.sourceforge.net/ __________________________________________________________________ Gesendet von Yahoo! Mail - http://mail.yahoo.de Bis zu 100 MB Speicher bei http://premiummail.yahoo.de
