Re: APT archive
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
lucifer@lightbearer.com http://users.lightbearer.com/lucifer/
Reply to: