Subject: pkg/18966: binary packages have no idea what architecture they are for.
To: None <firstname.lastname@example.org>
From: None <email@example.com>
Date: 11/08/2002 19:17:25
>Synopsis: binary packages have no idea what architecture they are for.
>Arrival-Date: Fri Nov 08 00:18:00 PST 2002
>Originator: matthew green
>Release: NetBSD 1.6I
people's front against (bozotic) www (softwar foundation)
System: NetBSD what-time-is-love.eterna.com.au 1.6I NetBSD 1.6I (_what_) #75: Sat Oct 5 13:53:33 EST 2002 firstname.lastname@example.org:/var/_what_ macppc
binary packages have two problems related to architecture:
- the names don't include the architecture. i'm sure
that the argument is that they belong in "<arch>/All"
but when you download a single package and a week later
you don't know what architecture it's for...
- the package system itself seems to be completely
ignorant of architecture a package is for. this means
that you can pkg_add a binary package for a different
architecture. it could be argued that this is a feature
that makes pkg_add useful for diskless clients(*). i
would agree, but i would also argue that the *default*
pkg_add should not allow packages for a different
architecture be install. a flag should be required.
(*) to be honest, pkg_add's support for diskless clients appears to
be pretty poor. the "-p prefix" flag only applies to the first "@cwd"
and thus it can't really be used as "-p /export/root/client/usr/pkg",
one really needs to use it with chroot.
install a binary package for the wrong architecture and be
puzzled why the package doesn't work.
i suggest two changes:
- binary package names are changed to include the
$MACHINE_ARCH that these binaries are for.
- binary packages are enhanced to include the
$MACHINE_ARCH (+MACHINE_ARCH file?) and pkg_add will
only allow installing packages for a different
MACHINE_ARCH if given a (new?) "force" flag.