it seems to me that these are two different things since bsd isn't a hardware type; it's a kernel and operating system. so it seems to me that 'debian-bsd' should be something different from 'debian-sparc' or 'debian-alpha' since it's not using a linux kernel.
seems like it would be make more sense to use stuff that is already part of *bsd where possible (UFS, libc, bsd utilities) but take a debian approach to development and packaging etc. thus it would be more like *bsd with a different approach (not just *bsd with a good packaging system...) i am not a huge expert on operating systems, but it seems that using gnu utilities and ext2 and making it more gnu/linux-like is taking away a lot of what makes *bsd so great; not that these are bad, but if people wanted them they'd use gnu/linux :> looking through the archives it seems that this is the never-ending debate... just my $0.02 w GT wrote: > > Quoting Will Yardley <[EMAIL PROTECTED]>: > > > i'm new to the list > > Me too. Hi there! :) > > > on another note, do people think that there's enough resources > > (person-wise) to support developing an entirely new set of packages? it > > seems that some method of converting ports to a debianized format > > compatible with apt would be nice.... debian is already fairly cautious > > / slow with releasing new stuff, and it seems that it would be difficult > > to keep up with (presumably) considerately less people involved. > > > > since the ports use standard makefiles, and the patches are included, > > would it be hard to use these to build the packages? (i'm sure this may > > have been discussed before, so i apologize if that's the case). > > I'm not sure if it would be very easy to do, but I don't think it > matters much. What we need to do is make standard Debian packages > compile under Debian/BSD, same as all the other Debian ports do -- > if this is to be a true Debian port, we'll need to be able to take > a standard Debian source package and have it compile under debian-bsd > as easily as it compiles under debian-sparc or whatever. We don't > want to make whole new packages, nor do we want to use *BSD pkg stuff. > We want to do it "The Debian Way(tm)". > > Mostly what's been discussed in order to make this feasible is to > either (a) port glibc to BSD, or (b) patch existing packages to work > with BSD libc. But apparently porting glibc to BSD would be a major > pain, and patching every existing package that doesn't work with > glibc would also be a major pain. I'm wondering if a third option > isn't possible: (c) create a new library that runs on top of BSD libc > that simply takes glibc calls that aren't in BSD libc and provides > them, or functions that operate differently would be "wrapped" by our > glibc compatible version. It seems to me this would be easier than > either (a) or (b). It would give us glibc compatibility for the > GNU tools while still allowing native BSD stuff to work fine (and I'm > a big fan of the idea of providing a /usr/ucb folder (or whatever we > want to call it), but then I'm an old Solaris user). Is there a list > somewhere of what the differences are between BSD libc and glibc, or > is this one of those lists we'd end up compiling ourselves in the > process of attempting to make this work? > > -- > GT <[EMAIL PROTECTED]> http://www.dreamsmith.org > "We don't receive wisdom; we must discover it for ourselves after a > journey that no one else can take for us or spare us." - Marcel Proust > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
