Web lists-archives.com

Re: Exclude some architectures from an architecture-independent package ?




Le 30/05/2019 à 19:28, Adrian Bunk a écrit :
>> Well, that's what I thought to do at the beginning, but the docs say
>> that binary package duplication is a bad thing, and I didn't know if
>> four copies of a 13 KB package (so a waste of 49 KB per mirror, which
>> would seem negligible unless you're a purist) was an "acceptable"
>> exception, hence my asking here for advice.
>> ...
> 
> Which docs exactly?

Debian Policy, 5.6.8:

"Specifying a list of architectures or architecture wildcards other than
any is for the minority of cases where a program is not portable or is
not useful on some architectures. Where possible, the program should be
made portable instead."

https://www.debian.org/doc/debian-policy/ch-controlfields.html#s-f-architecture

I probably focused too much on the last sentence, as I realize now that
this corner case matches exactly the "not useful on some architectures"
part.

Also, at the beginning of my research, I didn't know that only four
architectures supported ACPI, I thought it was supported on all of them
except the ones for which the initial bug report [1] stated a build
failure (armhf, ppc64el and s390x). That's why I was more inclined on
finding a solution to exclude some architectures, than enabling only a
few of them; I didn't want to maintain on the long term a list of
architectures built manually, both for officially and non-officially
supported ones, and both for Debian and Ubuntu (they change nearly over
every release, maintaining it would have been tedious, and a nightmare
to backport).

All in all, I started this journey on the wrong direction, but
everything is clearer now.

[1] https://bugs.launchpad.net/ubuntu/+source/acpi-call/+bug/1830040

> Developer manpower is scarce and mirror space is no longer a problem
> in practice, so I wouldn't waste time worrying about mirror space.
> 
> And definitely not for such tiny files, the largest files on the
> mirrors are > 1 GB.

Thanks for clarifying that. I think I'll go for the binary package
duplication then.

Regards,

-- 
Raphaël Halimi

Attachment: signature.asc
Description: OpenPGP digital signature