Re: libc strategy
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 <william@hq.newdream.net>:
>
> > 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 <gt@dreamsmith.org> 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 debian-bsd-request@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: