Re: discover-udeb: Depends: libdiscover1 but it is not installable
stappers@stappers.nl (Geert Stappers) writes:
> On Tue, Dec 09, 2003 at 07:39:07PM -0500, Joey Hess wrote:
> > Geert Stappers wrote:
> > > libdiscover1 is installed on that build computer.
> > >
> > > Doing `grep -R libdiscover1 *` didn't bring up a usefull hint.
> > > What other things do I have to hunt down that dependency.
> >
> > This must be a consequence of Goswin's grody hack in get-packages:
> [ get-packages fragment that modifies APT status file ]
>
> > So even though you have it installed, apt is coaxed to not know it is
> > installed. Goswin and I discussed this for hours, I think it is 100%
> > useless to dummy up a status file, and I never got an answer that was
> > satesfactory to me about why it's needed.
>
> I missed that discussion. So I missed also the _why_
Either way breaks for some. You have to little packages installed, I
have to many. Turning the status file off will only work for udebs and
then only for most cases. And its only udebs with broken depends that
make the problems with the empty status file.
The problem you see is secondary: The right[tm] way for mklibs is to
not use system libraries in which case all libs must be provided by
udebs or debs that get installed into the tmp/tree driectories. As a
favour to joey I didn't use the debs (so he doesn't have to download
the huge Packages.gz file over modem on every update) but pulled in
the needed library infos from the system. Shouldn't have done that
seeing all the trouble its causing.
One thing that will completly break down without an empty status file
is building d-i images with an older libc than your systems (and what
some essential packages have a minimum version). Installing the older
libc6-pic file into the ramdisk for mklibs will cause apt to remove
essential packages (not realy since they aren't installed in the
initrd) and break the build. But even with the right glibc the
downloading of debs for the d-i cdrom images (not debian-cd build
ones) will break down if any installed deb conflicts with the base
debs, i.e. i you don't have the default MTA installed (I still
have exim3 and not exim4 for example).
> > Try either adding libdiscover1 to the list, or changing the APT_GET
> > to not use the dummy status file. I've done the latter in my own tree,
> > for weeks.
>
> Besides adding libdiscover1, also discover-data was needed.
There is no dicover-data. The right package is discover-data-udeb as
it stands. If the archve scripts could get fixed to allow debs and
udebs of equal names that could be avoided.
There is also no libdiscover1 udeb. Nothing may depend on libdiscover1
strictly speaking. Doing so is just plain broken, sorry.
The discover-udeb won't be installable over the net for this
reason. It will only work in the initrd itself. You need an
libdiscover1 udeb. period.
> Removing the status file tweaking stuff did also work and much cleaner.
> Please apply attached getpackages.patch
Don't. Fix the broken udebs, fix the archive scripts to allow equaly
named packages for debs and udebs to get all the shlibs bugs fixed.
Package up the missing libraries as udebs or convince Joey to allow
me using debs.
> The udeb pkg-list was incomplete, see baselist.patch.
>
> >
> > --
> > see shy jo
>
> Geert Stappers
MfG
Goswin
Reply to: