Dnia 2013-11-17, o godz. 09:24:26 Kent Fredric <kentfred...@gmail.com> napisał(a):
> On 17 November 2013 01:39, Martin Vaeth > <va...@mathematik.uni-wuerzburg.de> 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. Unless I'm misunderstanding something, you are not correct. You can surely do something like: RDEPEND="abi_x86_32? ( dev-libs/c[abi_x86_32(-)] )" (and a matching multilib_src_configure) > 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. You mean having N forks where N is the number of ABIs (3 for x86 + 3 for mips currently). You will need to mask some (or all) of them for other arches, and so on. Then we may want to add support for another multilib arch/ABI... -- Best regards, Michał Górny
signature.asc
Description: PGP signature
