On 05/07/2016 03:59 PM, Geert Stappers wrote: > On Sat, May 07, 2016 at 03:23:41PM +0200, Geert Stappers wrote: >> >> My gut feeling says that the package 'sse-support' is sabotage on architecture "any". >> > > This is from #823465 http://bugs.debian.org/823465 > > | I'm afraid there's not enough people who care about 586 enough to maintain > | it. And the bad decision of i386 to stick to a single arch during its whole > | life makes it hard to do so on debian-ports. Compare with ARM: there's arm > | armel armhf arm64 arm32(arm64ilp32) -- it frequently refreshes the ABI to > | make use of new CPU features, which also makes it easy to keep old compat > | without forcing new processors to stay with the lowest common denominator. > > > I now have a better idea _why_ a sse-suport package. > > My concern is how should look a Debian control file at source level ( arch all ). > At arch Intel makes a 'Depends: sse-support' sense > Having at arch ARM 'Depens: sse-support' also, will prevent install, but not `build`. I really don't get what you are saying here. Of course one would NOT have an arch: any package in Debian that depends on sse-support on non-i386, you'd put in Depends: sse-support [i386] in debian/control and the package build would then add the dependency on i386, but not and anything on other platforms. (If the package in question even supports other platforms than x86 in the first place.) Why so critical? The current situation is that if there's a package in the archive that now only works with SSE extensions, and is not easily portable to non-SSE (for example, if it contains hand-written assembly code), then the only recourse that's available _now_ is to drop i386 from that package's architecture (because it will segfault without a good error message) - or to add detection in preinst... (Because porting is not always an option, especially if it's lots of code.) This does not, however, excuse packages to force SSE support if a package CAN support other hardware, and it wasn't meant to. It is meant to cover the cases where a package is either not available on i386 at all or available to at least some users. I fail to see why you would think this is a bad thing? @Adam: One suggestion though: since this might also come in handy in other places, I'd recommend you name the source package something more generic (such as cpu-support or so, assuming that's not taken already, I didn't check), and have it generate a binary package with the name sse-support. I'm pretty sure that other cases could come up with a similar requirement in the future, and that way they'd easily find a home. Regards, Christian
Attachment:
signature.asc
Description: OpenPGP digital signature