Dnia 2013-11-15, o godz. 14:53:00 Ben de Groot <[email protected]> napisał(a):
> As I see it now, with respect to multilib, we have three competing > solutions, but not a clear direction which way we want to go as a > distro: > > 1: emul-* packages > 2: multilib-portage > 3: multilib.eclass > > I would like to vote for option 1, as it is the least intrusive and > does what we need. If it is really felt we need a more complete > solution, then my vote would be for 2, since 3 is too intrusive and > more likely to break or complicate stuff for normal users. > > If you say council should take more of a leadership role, then maybe > this issue can be decided by council and a clear direction be taken by > the distro as a whole? Then those who oppose the choice made can > either put up or shut up, and we can all work at implementing the > chosen solution. And what does, say, a Council decision change? Sure, Council can affect opinions of some developers and so on but this is something that needs real work, not talking and deciding. Sure, you can convince the developers that X is better than Y but you also need to find someone who will actually work on X. And I think the actual work done by *different* people shows which solution is most preferred by the community. This is not something that judges whether it's the best one, but probably it'll the most maintainable one. Think of bus factor. About your list, let's first note that emul-linux are not dead. We're working on getting a replacement but we aren't dumping them yet and we're actively encouraging developers to use any-of deps to support both multilib packages and emul-linux. As you probably have seen, emul-linux even had an update recently. On the other hand, let's be honest -- emul-linux are basically single-handedly maintained by Pacho. I can't talk for him but if you really want to keep that supported long-term, you need to find people who are going to work on them actively. I don't know the exact number of people actively working on multilib-portage but I haven't seen any progress on getting all the formal stuff done. And remember that this particular idea requires much more work since it assumes the spec becoming part of immutable EAPI -- getting it all right, extensive testing, considering all the corner cases, etc. One thing I can tell is that gx86-multilib is getting the widest support of all the solutions. It has most active developers, most active helping users and some support from random developers that just maintain their packages. It requires less work on the formal side, and gets better testing for the simple reason that you need to do it per-package. -- Best regards, Michał Górny
signature.asc
Description: PGP signature
