Re: RFC: future of libfreebsd
The thing is that we have to keep those symbols to not break existing
software, but yes, those functions should not be considered as part
of libfreebsd anymore.
We could ship the same libfreebsd0, only drop libraries from
libfreebsd-dev. And drop whole libfreebsd source package later.
I didn't check, which are the needed functions used by packages
depending on libfreebsd0. Could this check be done easily ?
Probably UDD can do that for the packages that are already in the
debian.org archive, but not for the one that are not yet available.
That said I doubt that a lot of packages depends on libfreebsd0, so
doing the work by hand should not be that difficult.
Despite our freebsd-* packages, only miredo, fuse and qemu b-d
on libfreebsd-dev. The qemu is not yet built for debian.org archive,
the miredo and fuse should use only devname_r()/devname().
We have to decide, before eglibc 2.10 will go into unstable,
which functions could/should be moved into eglibc and do it.
Agreed. Or have to wait for 2.11 :(
getbootfile() *may* be implemented in libbsd.
It should be used only by libkvm0.
For link_addr() and link_ntoa(), I currently don't have an opinion, we
should probably look where they are used.
It should be only in freebsd-net-tools package.
Probably: dctrl-tools, for, dget, dpkg -x, find, nm, grep. Want me to
have a look?
It would be nice to confirm my expectation.
It depends how costly it is.
Petr
Reply to: