On Mon, Jul 19, 2010 at 07:02:32PM +0100, Hector Oron wrote:
> 2010/7/18 Steve Langasek <vorlon@debian.org>:
> > I'm puzzled why dpkg needs a unique triplet for a port. dpkg needs to map
> > port names to triplets, but why does it need to do the inverse? And if it
> > doesn't need to map triplet->port, why would the triplet need to be unique?
> AFAICS `dpkg' relais on -dumpmachine from `gcc'
> scripts/Dpkg/Arch.pm:68: my $gcc_host_gnu_type = `\${CC:-gcc}
> -dumpmachine`;
> Then all the magic starts...
> How would `dpkg' can then map GCC tuplets into Debian triplets being
> the same with different Debian architecture names?
It wouldn't. I don't see a compelling reason for dpkg to do this at all.
Your quote shows that dpkg *does* do this today, which I didn't remember
before this conversation, but that's not an explanation for *why* it does -
as opposed to dpkg directly recording what its current architecture is.
> > There is a need for a distinct port name; I think this is also not a
> > Debian-specific problem, it's a problem common to any distributions that
> > want to do what's described here.
> There is no need of distinct port name for 'any' distro.
This is a rather straightforward namespacing issue. If a single
distribution wants to ship packages for multiple ports on a single ftp
server (or on a common mirror network), there needs to be a way to tell them
apart, which implies distinct filenames. We accomplish this by including
the architecture name in the filename of all .debs, and IIRC rpm
distributions do similarly.
Calling this something other than "architecture" ("ABI", "subarch", etc) is
quite beside the point - we still need a distinct name for any files we
intend to ship in the main archive.
> As I had stated previously my though on another thread [2], there are
> two different cases mixed on `multiarch':
> a) Co-installing libraries (in x86 world, with compatible ABI) which
> main purpose it is to be able to run `non-free' software.
> b) Co-building, which it is the part that affects me the most and can
> be easily solved using sysroot switch on GCC, without any upstream
> changes.
> Using sysroot approach you might be able to co-install foreign (other
> arches) libraries into the sysroot for case a) - it even lets the user
> have multiple systems with same ABI and architecture, but with
> different libraries (in the case you want to cross build non Debian
> systems).
sysroot is irrelevant to what multiarch aims to achieve.
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer http://www.debian.org/
slangasek@ubuntu.com vorlon@debian.org
Attachment:
signature.asc
Description: Digital signature