On Thu, Oct 18, 2012 at 12:07 AM, Ryan Hill <dirtye...@gentoo.org> wrote: > On Wed, 17 Oct 2012 15:00:12 -0400 > Rich Freeman <ri...@gentoo.org> wrote: >> I think the whole developers-can't-handle-47-EAPIs thing is a red >> herring. The fact that there are packages written in Erlang in the >> tree doesn't cause me any issues even though I haven't had to do any >> work in Erlang. If I ever wanted to maintain such a package then I'd >> take the time to learn it as needed. Likewise, if I wanted to >> maintain a package that used EAPI joe and I really prefer to work in >> EAPI fred, then I'd revise it at my next convenience. > > Well, it's not just about ebuilds you maintain. Think about something > like the gcc-porting trackers where you have to touch a lot of ebuilds > across the tree. You really do have to have a working knowledge of the > differences between EAPIs to do so. My browser bookmark to the EAPI > cheatsheet is one of the more frequently used as it is.
Can't you just ask the maintainers to fix their ebuilds? And if they don't respond or at least cooperate, well, then treeclean them. I don't think that library maintainers should have to bend over backwards to fix reverse dependencies, within reason. If out of the whole tree two packages are blocking an upgrade, give a deadline or treeclean them. If we have 47 bazillion packages that don't work on the newer lib, then slot it and bug upstream. I do agree that trying to auto-mangle ebuilds from 47 different EAPIs doesn't make sense. Just assign a bug to the maintainer saying "do this to your ebuild, or get it on EAPI foo so that I can fix it, by <date> or it is gone." The deadline is important - I've seen a pattern on -dev where bugs linger without deadlines for months, and then a deadline of two days is imposed, and then a big flame war breaks out. Just set a deadline up-front and make it reasonable. Rich
