libc6 migration -- xlib
Is there a web page or other document that explains what our strategy
for libc6 is? I'm not talking about random comments on the list, I
mean something nailed down that I can refer to...
In particular, I've got a few issues to work out.
1) libgdbm -- libc6 includes libdb, and therefore gdbm is
supposed to be unnecessary. If this is true, it needs to be written
down, so I can point people at it -- otherwise, I need a strategy for
renaming the package (since there needs to be a libgdbm.so for libc5
and a seperate one for libc6... the former isn't changing, obviously;
how do we change the latter so that "-lgdbm" still works for users
building against it? [since db can't read gdbm files, that *will*
continue to happen.])
2) X -- a full release of X requires tk41-dev to build
XF86Setup (it uses the static lib, so the end-user doesn't need it.)
But tk41-dev probably won't be available for libc6 until I release X.
Ooops :-) I can hand-release xlib6-dev by itself, (into experimental,
perhaps?) so that someone can build the tk packages... or I can build
that particular lib by hand until then (but then would still have to
leave X in experimental unless I took over the package, eww.) And
what *do* I name things? I'd guess that xlib6 is untouched, the
version built with libc6 gets called xlib6-libc6 (eww), I release an
alt-xlib6-dev that replaces and provides xlib6-dev (which alt-libc5
doesn't?) and then xlib6-dev can be the new version? Am I missing
anything?
3) can I drop the a.out-only "dlltools" package now? :-)
4) does anyone who uses gnat (I'll ask again later, I probably
won't even try that rebuild until 3.10 or later comes out) care if I
just shove gnat along to purely libc6-based?
_Mark_ <eichin@kitten.gen.ma.us>
The Herd of Kittens
A Debian Maintainer
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
debian-devel-request@lists.debian.org .
Trouble? e-mail to templin@bucknell.edu .
Reply to: