Re: amd64 and sarge
On Fri, Jul 30, 2004 at 03:52:58PM +0200, Goswin von Brederlow wrote:
> Packages containing libraries and binaries would violate 8.2. No point
> making special cases for it, just file bugs.
/var/lib/dpkg/info$ grep -il bin/. *.list | xargs fgrep -il .so | sed 's}[.]list$}}' | fmt
> >> It bloats a base install from ~150 to ~300 mb.
> >
> > No, only the shared libraries need to be duplicated. You don't duplicate
> > docs, executables, etc. etc.
>
> Call it ~250 MB then. Still bloat 99% of all users don't want or need.
I count about 20MB for the i386 copies of the shared libs in base.
/var/lib/dpkg$ perl -00ne 'print if /Section: base/' status | awk '/Package:/{print $2}' | sed 's}^}info/}; s}$}.list}' | xargs cat 2>/dev/null | fgrep .so | xargs cat | wc -c
So we're talking about bloating base from ~150MB to ~170MB.
> > The i386 library debs have to not conflict with needed amd64 lib debs,
> > or they won't get installed. I'm imagining that ia32 debs can be made
> > to satisfy these dependencies.
>
> How do you detect conflicts or doesn't conflict. There is nothing in
> your proposal about that. That looks like wishfull thinking.
Standard dpkg resolution for dpkg. Standard ld.so resolution for runtime.
Add onto that that the ia32 libs provide their equivalent package with
:i386 appended.
> > %s/ core / base/g
>
> Base would reduce the number of packages you can run. So your proposal
> would be less than pure64.
My proposal is based on pure64. Nothing is eliminated from pure64
without providing a replacement.
> > Building packages for multiple architectures is the thing that multiarch
> > supports that biarch doesn't.
>
> Then how do you want to build your debs? They are supposed to conatin
> i386 and amd64. Your proposal seems to desperatly need the ability to
> build both flavours and then merge them into one deb.
Native i386 packages can be built on i386. amd64 (including ia32)
can be built on amd64.
> > Sounds like it would be worth modifying libtool to do this systematically.
>
> Doesn't work. libtool scripts are contained in the source
> packages. After changing libtool you need to change every source
> package to update the scripts.
Ok, so we can't support i386 libtool using my proposal.
> >> The .pc files are used by gnome and gtk. ls /usr/lib/pkgconfig/
> >
> > Sounds like it would be worth modifying gnome's pkgconf suport to address
> > this systematically. [Whatever it is that generates the .pc files.]
>
> How? Both i386 and amd64 *pc files would end up in /usr/lib/pkgconfig/
> for most things. Your proposal doesn't keep libraries seperate. You
> need another hack to seperate 32bit and 64bit stuff just like your
> proposed gcc hack.
My proposal doesn't have two architecture's versions of the same package
installed on the same machine. 32 bit is only installed via IA32 or by
not having the amd64 package installed. That resolves every instance
of that conflict I'm aware of.
--
Raul
Reply to: