W dniu sob, 03.03.2018 o godzinie 22∶51 +0900, użytkownik Benda Xu napisał: > Hi Michał, > > Michał Górny <mgo...@gentoo.org> writes: > > > > I am sure you are aware that Prefix has two variants: one is > > > prefix-rpath targeting MacOS, Solaris, AIX, Cygwin, Interix and a subset > > > of GNU/Linux; the other is prefix-standalone, targeting GNU/Linux and > > > Android/Linux.[1] > > > > > > For LLVM example, it is prefix-rpath, which hosts its own overlay at > > > repo/proj/prefix.git. Besides LLVM there are other hacks at present in > > > the overlay. But we still keep the ultimate goal of merging prefix.git > > > into gentoo.git. > > > > I am also keeping old versions of LLVM for Prefix team. That's why I'd > > really prefer to get rid of them and have them in some common overlay > > that all Prefix users can use. > > Yes that's true. The case of LLVM for prefix-rpath is similar as glibc > for prefix-standalone. > > For the argument of overlay refer to the message below vvv > > > > What we are discussing in this thread, however, is prefix-standalone, it > > > uses the official gentoo repository without any overlay. It works > > > perfectly for kernel-2.6.26+ and linux-3.2+. So, creating an overlay of > > > 2 ebuilds for prefix-standalone is an overkill. > > > > Maybe it is. But isn't making maintenance of Gentoo packages more > > complexity for Prefix an overkill? We are effectively switching > > from trivial model of 'assign bug with X to maintainer' to checking > > which maintainer applies to which version of X. > > I am on the toolchain alias, and I am interested in joining the project. > I will be responsible to deal with all the bugs for glibc-2.16 and > glibc-2.19. Bug wranglers' work load does not change. > > Yes, I apologize this will generate some noise for toolchain@g.o. But I > anticipate people on the team are interested in receiving those emails. >
That's not a solution. That's cheap a cheap excuse that works for one package, for today. It does not solve the generic case, it does not mean that other members of toolchain or any other team will not end up having to remember extra rules like 'do not remove this ebuild because X wants it'. -- Best regards, Michał Górny
