Hi!
On Sun, 2015-12-06 at 21:39:59 +0100, Axel Beckert wrote:
> Package: dpkg
> Version: 1.18.3
> Severity: wishlist
> it's rather tedious to find the correct "Architecture:" value for a
> binary package if only one or two architectures need to be excluded.
I think I've mentioned this on the other bug report, but I conisder
this the wrong approach altogether.
There are several reason a package will only build on a set of arches,
or cannot be built or will not build for some arches:
1. The code is kernel, cpu or device specific. This case means that
upstream needs to add support for new stuff, so using a whitelist
is the correct thing to do, things like:
"linux-any", "any-amd64" or "powerpc, ppc64" respectively.
For the device case this is more tricky, as there can be cases
where some devices will never be present on some arches, so
blacklisting those specific cases might makes sense (see §3, §4).
2. It fails to build, or does not work due to a transient bug in a
Build-Dependency. In this case restricting the architectures seems
bogus and counterproductive, as it might mean changing lots of
packages. The correct thing here, is making those Build-Depends
uninstallable or unavailable, for example by forcing them to FTBFS,
or say for C code to include #error pragmas in their exported
headers, so that nothing can be built while they are broken. This
requires only removing brokenly built packages, and the rest will
be taken care of automatically by wanna-build.
3. If this is a toolchain issue, then that does not affect a ton of
packages, then either adding a workaround, or making the package
fail on that specific arch instead of generating a broken binary is
IMO better.
4. Although undesirable we still have the Package-arch-specific
blacklist.
Using a whitelist to avoid transient problems on specific arches has
the problem that if this persists in time it needs to be updated for
every new architecture that we introduce, and the porters need to
evaluate whether this package is portable or not, etc. This does not
scale.
Perhaps for §3 using an explicit blacklist would be nicer, because it's
declarative, instead of having to trigger a build failure which is also
more costly, but see the other bug report. :)
> As I don't want to list all architectures listed by "dpkg-architecture
> -L", I had to use
>
> dpkg-architecture -L | fgrep -- - | awk -F- '{print "any-"$2}' | sort -u
>
> to get an idea, which any-… wildcards probably exist. I then run into
> the fact that neither any-armhf nor any-armel exist -- thanks to Lintian
> for making me aware of.
> I suggest to use "--list-known-wildcards" and "-w" as commandline
> options for this list.
The problem with this approach is that this will still get you an
insane amount of wildcards, many of them overlapping. What you'd
really want is: for a given set of arches, give the minimal set of
wildcards and specific arches that will exclude them.
For unrelated reasons I had to create a list of all currently valid
wildcards, these amount to 2688! So I'm not sure this is something
sane to output, as a starting point to generate those Architecture
lists, really. :) Attached is the script.
Thanks,
Guillem
#!/usr/bin/perl
use strict;
use warnings;
use Dpkg::Arch qw(get_valid_arches debarch_to_debtuple);
my @arches = get_valid_arches();
my %wildcard;
my @wildcards_base = qw(
any
any-any
any-any-any
any-any-any-any
);
foreach my $archname (@arches) {
my @tuple = debarch_to_debtuple($archname);
my @wildcards_arch = (
# Two element tuples.
"$tuple[2]-any",
"any-$tuple[3]",
# Three element tuples.
"$tuple[1]-$tuple[2]-any",
"$tuple[1]-any-$tuple[3]",
"$tuple[1]-any-any",
"any-$tuple[2]-$tuple[3]",
"any-$tuple[2]-any",
"any-any-$tuple[3]",
# Four element tuples.
"$tuple[0]-$tuple[1]-$tuple[2]-any",
"$tuple[0]-$tuple[1]-any-$tuple[3]",
"$tuple[0]-$tuple[1]-any-any",
"$tuple[0]-any-$tuple[2]-$tuple[3]",
"$tuple[0]-any-$tuple[2]-any",
"$tuple[0]-any-any-$tuple[3]",
"$tuple[0]-any-any-any",
"any-$tuple[1]-$tuple[2]-$tuple[3]",
"any-$tuple[1]-$tuple[2]-any",
"any-$tuple[1]-any-$tuple[3]",
"any-$tuple[1]-any-any",
"any-any-$tuple[2]-$tuple[3]",
"any-any-$tuple[2]-any",
"any-any-any-$tuple[3]",
);
foreach my $wildcard ((@wildcards_base, @wildcards_arch)) {
push @{$wildcard{$wildcard}}, $archname;
}
}
if (defined $ARGV[0] and $ARGV[0] eq '--map') {
foreach my $wildcard (sort keys %wildcard) {
my @arches = sort @{$wildcard{$wildcard}};
print "$wildcard => @arches\n";
}
} else {
foreach my $wildcard (sort keys %wildcard) {
print "$wildcard\n";
}
}
1;
