On 17 November 2013 01:39, Martin Vaeth <[email protected]> wrote: > > This is really a severe restriction since the motivation > for installation can be very different for these variants. > For instance, for a native ffmpeg the user might want support > for a lot of codecs/devices while for the 32 bit variant > the user might want only support for those codecs/devices > which are needed for some special application. Nevertheless, > the same useflags mean that he has to build the same > (with all implied dependencies) also for 32 bit.
Imo, thats a really good point. The convenience of having 1 ebuild support both 64bit and 32bit is sort of like a conflation of classes, because it behaves similar to having 2 ebuilds dove-tailed into one. Being able to specify different dependencies for different arches seems something that would be useful, especially in the following cases: Imagine, an ebuild provides 32bit and 64bit implementations. User only needs USE="a b c" for the 64bit version, but only USE="a" for the 32bit version. "c" however, on 32bit, needs a dependency to make it work on 32bit to smooth over a difference. But that dependency is unneeded on the 64bit version. Which means that USE="arch_32 arch_64 a b c" pulls in more dependencies than necessary to satisfy the users systems requirements. Just the overhead work to debride it and have a seperate package, or a seperate slot per ARCH_ABI might be more problem than its worth. So its just a question here of which tradeoffs are more acceptable for most of our audience. ( Yes, I'm referring to a similar question that came up the other day as to the advantages of having <gvim> independent from <vim> and <vim-core>, and being able to have different USE flags for each was seen as a distinct advantage of the separation ) -- Kent
