On Mon, Jan 21, 2002 at 01:32:49PM +0000, Matthew Garrett wrote: > On Sun, Jan 20, 2002 at 09:58:11PM -0700, Joel Baker wrote: > > > On a sidenote... I'm a bit worried at the errors I'm seeing out of the > > shared-lib dependancy autogenerator stuff. Is this still broken? (I don't > > mind re-building all of the packages, once it's fixed, if so, but I would > > sort of like to know...) > > If it's stuff like libc and libutil, that'll be because I neglected to put > any shlibdeps stuff in the libc package. This probably needs to be sorted > at some point (and it needs to be split into a -dev too, for that matter).
Libc is one of the main culprits. Though some packages that I built also seem to have issues. Out of curiosity, what do you need beyond what the basic dpkg-buildpackage run does, to make a library get properly detected by dpkg-buildpackage? On another sidenote... it seems that the state of the base chroot is still broken enough that packages are considered flawed (and thus, APT won't work inside it directly). I'm working on recompiling all of the Essential ones that I can get to work, but some of them will require bug resolution first (from upstream). On a third note: there is already a formal method for naming/storing local patches and having them get automagically applied with the build tools. I think that a CVS repository is great, but... without stuff actually getting built into packages somehow, that won't help us much, IMO. Much of the work which I have listed as 'pending bug resolution' is aimed towards one goal - specifically, getting a buildd instance running that can automagically do the grunt work recompilations for us (thus keeping up-to-date with the tree in unstable for any package that can actually be compiled directly from the upstream sources). And I did file one bug that is pretty much Debian-BSD specific, already. To wit, flex won't build, solely because it assumes that gettext routines live in libc, rather than checking both libc and libintl. Since the package for grep has a macro to handle exactly this situation, which is open for public use, I filed a point and requested a fix. I shouldn't say BSD specific, I guess; it's specific to 'any port which does not use glibc'... but anyway. We're a recognized port. When we have reasonably easy problems to fix that are endemic to an entire class of ports, or endemic to the building setup itself - we *should* be filing them. Most of the developers I've had any contact with on these things are quite happy to fix things, if you can hand them an elegant solution as well as a problem. And they *will* have to get fixed at some point, upstream... -- *************************************************************************** Joel Baker System Administrator - lightbearer.com [EMAIL PROTECTED] http://users.lightbearer.com/lucifer/
