Re: dpkg-architecture adaptations for e.g. uclibc
On Tue, Jun 13, 2006 at 12:29:36PM +0200, Pjotr Kourzanov wrote:
> Volker Grabsch wrote:
> > On Mon, Jun 12, 2006 at 04:32:16PM +0200, Pjotr Kourzanov wrote:
> >> I have not investigated this further but it looks like the mingw32 package
> >> requires a patch so that it generates cross versions for w32-i386
> >> (GNU: i486-mingw32msvc), and not i586-mingw32msvc.
> >
> > I already discussed this point with the author. Maybe "w32-i386" is a
> > bad name, and "w32-i586" would be more accurate
>
> My guess would be that the binaries you get from M$ are optimized for i586 right?
> file on /usr/i586-mingw32msvc/lib/crt1.o says "80386 COFF executable not stripped
> - version 30821",
> What's the target CPU for the wrappers in mingw32-runtime?
I'm forwarding this to Ron Lee, the Debian maintainer of the mingw32 package(s).
Maybe he can explain these details to us.
> > This sounds reasonable. BTW, why do you call it "ming" instead of "mingw"?
> w from mingw is from w32 no? So, it's Minimalist GNU for w32, so I suppose w32 would be an OS,
> msvc would be LIBC, and ming would be sortof ABI used with w32-msvc.
Well, I think that's okay, although I've never heard of any "Minimalist
GNU" other than the "Minimalist GNU für w32". ;-)
> > Also, for every architecture, there are some defaults for the LIBC and ABI.
> > For w32, msvc and mingw is a very good default for various reasons. Does
> > your naming sheme allow that? (i.e. making w32-i386 equivalent to
> > w32-i386-msvc-ming) Or are there only overall defaults for LIBC and ABI
> > for all architectures?
>
> There is a mapping in the ostable (e.g. linux-> linux-gnu). I see no entry for w32
> there though, but you could add something like "w32 w32-msvc-ming pc-mingw32" as well as
> "w32-cygnus w32-msvc-cygnus pc-cygwin" or something like that.
That sounds good.
> > That having said, I don't think it isn't the question whether one
> > wants to compile for i586, i686, etc. There are always good reasons
> > for some groups to do so. IMHO, the more important question is how to
> > name that thing. So it would be very nice if dpkg-architecture would
> > be flexible enough to support that, instead of stepping in the way.
>
> There are several alternatives, all of which have little to do with dpkg-architecture.
>
> 1. add a specific CPU to cputable and use that to compile all packages
> (I used to do that for ARMv4 and ARMv5te). This might not be acceptable in Debian.
Why not? Until now, I just heart about feelings .. about your feeling
that it's and Martin Guy's feeling that it sounds good. Were are the
facts? What are the real problems that may arise when adding more CPU
types to dpkg-architecture? What are the counter-arguments that make you
think it won't be acceptable?
> 2. create a separate repository with optimized binaries but still targeting i386 (or arm).
This may lead to a lot of confision and broken installations. I think,
your 3rd option is superior to this one in every aspect.
> 3. for some packages create optimized versions with CPU embedded in the name such as
> mplayer-i586.
Of course this is always possible.
However, these packages are (AFAIK) created in a completely different
way. They are part of the debian/rules and not created via dpkg-cross.
They are a work around the inability of apt to automatically use the
best suited binary packages. (e.g. uses on a i686 system the mplayer-i586
instead if mplayer-i386, and the kernel-image-i686)
Packages like mplayer-i586 are created by very redundant entries in
debian/rules ... exactly such redundancy is removed by dpkg-cross.
> I think the problematic part would be in apt or dpkg, where a decision would need to be
> made from where and which packages to install.
I don't think this would require a change in apt.
Of course, if you want to allow, e.g. the -i386 packaes to be installed
on a -i586 distribution, some bigger parts of dpkg and apt would have
to be changed. However, that is not my proposal at all. I don't intend
to create a w32-i586 Debian distribution which must also accept w32-i386
packages. I want to create an entire w32-i586 distribution.
(well, currently, I just want to provide cross compiling packages for
such a platform)
If one day apt evolves, packages like mplayer-i586 will step in their
way. The "Package:" field should not contain architectural information.
The "Architecture:" field serves that purpose.
All in all, I think there are two possible way to go:
1) insert more CPU types into dpkg-architecture
(e.g. i586)
2) handle an extra CPU list internally by dpkg-cross
(e.g. when cross compiling for w32-i586, create a package
like gettext-i586_w32-i386.deb)
I think, 2) is more work for dpkg-cross than 1) is for dpkg.
In addition, 1) opens the way for apt to support optimized
binaries natively in the future, and also to use dpkg-cross
for optimized packages, instead of additional debian/rules
entries.
Optimized and cross compiles packages are not that different, IMHO.
Greets,
Volker
--
Volker Grabsch
---<<(())>>---
Administrator
NotJustHosting GbR
Reply to: