Richard Yao posted on Tue, 17 Jul 2012 17:20:13 -0400 as excerpted: > The only thing that might require a merge is systemd and it is not in > @system. If we offered users the ability to choose rc systems, we would > still be supporting baselayout-1's rc system. If we start now, we should > bring that back.
Just addressing this little bit. The first and primary requirement for gentoo support of any rc/init system is that there's someone (gentoo dev or not, but baselayout was gentoo based so gentoo dev, or at least an advanced gentoo user, would be most likely) interested in maintaining it as upstream, and a gentoo dev (can be the same person) interested in maintaining the gentoo package/ ebuild. Gentoo's a community distro build on FLOSS, and if nobody's interested in assuming that work/responsibility for either gentoo or as upstream, ultimately, it gets tree-cleaned. Think about it. Consider things like kde3 and the kde-sunset overlay, too. That's not system init, but you're likely talking a job of similar size to continue to support it, with all the necessary initscripts, etc. kde-sunset is what happens when there's sufficiently interested users but no sufficiently interested gentoo devs, and/or a break in upstream maintainership (tho it eventually continued via the trinity project). Other (not even officially supported) init systems such as systemd that happen to be in our tree have at least that required minimum, and remain in the tree. kde3, despite having an active remaining gentoo userbase that continues to maintain it to some degree, didn't have that minimum. But I can say this. If there had been a sufficient level of gentoo developer interest in maintaining kde3 in-tree, it would have happened. Where there's developer interest, the product says around. There simply weren't developers stepping up to maintain it, so it ended up in an overlay. The same thing applies to baselayout-1... and for that matter, baselayout-2/openrc. If there had been sufficient developer interest in maintaining a working baselayout-1, it would have happened. Without it, no arbitrary ruling, no "if systemd, then baselayout-1", no "thus saith the council", will change it. Similarly, no wishing, "should be"s, decrees from council, etc, got baselayout-2/openrc stabilized, until williamh volunteered to push on it (certainly with help from others, but it didn't happen until someone stepped up to take personal responsibility for ensuring that it WOULD happen) until it got done. What you're seeing here with the unified / and /usr idea is more or less a similar dynamic, tho to quite a lessor extent. Upstreams are making their choices, and the gentoo maintainers of the corresponding packages are making /their/ choices. That's all there is to it. Upstream's going its way, but regardless of that, if there's sufficient interest among gentoo devs to guarantee patch development, testing, deployment, further testing, stabilization, and bug followup, gentoo WILL continue to make an initr*-less separate /usr work. But one of the things that had (at least until recently, I've seen arguments that it's breaking down now, with android, ubuntu, etc, going their own way to a greater extent than most before, and android especially is big enough to pull it off!) kept Linux from fragmenting the way the old Unices did was that while FLOSS ALLOWS forking, it also provides significant pressure to ONLY fork where one REALLY feels it's a high priority deal. Otherwise, it's simply less work and less expense, to go with upstream. That's why we have all these distributions, each generally different in their own way (and gentoo's certainly rather different from the generally binary distros, for sure!), but except for the features that a particular distro is emphasizing, that it thinks are important enough to be worth the trouble of maintaining that differentiation, it tends to stay pretty close to mainline. Which again, is exactly the dynamic we're seeing here. What we're going thru right now, with all the threads and discussion related to this, is simply debating whether, as a distro, gentoo considers this differentiation from upstream worth the cost of continued maintenance. Which is where the point I made above comes in. If there's no gentoo devs caring enough to make it their job to ensure that support remains, the default will simply be to follow upstream, only maintaining the minimal patches necessary to continue what gentoo, individually and collectively, finds high enough priority to be worth the time and effort cost to maintain the differentiation. And as of now, just as with kde3, the fact of the matter is that despite a decent level of interest from users, it doesn't look like we have the necessary interest from devs to commit to such support, long-term. What we're seeing is devs committing to maintaining support for the short and intermediate (?) future, out perhaps six months to a year or two, but the differentiation cost trend beyond that looks to increase quite dramatically, and at least at present, we don't have enough developers willing to commit to maintaining it beyond that. And the thing is, no "should"s are going to change that. If you (and other users, personally I'm in the middle, interested but not caring enough to really commit to it) want it, there's two ways to get it: 1) Start now, and either convince enough current devs or convince to join enough new devs, so when the time comes, that commitment can be made, even if it means a significantly increased patch load, to the point of de- facto or official forking. 2) Get ready for a user-managed overlay, similar to kde-sunset. Of course the other alternative would be to find a distro more suitable, but for a lot of gentooers, that's not an alternative they consider viable, as gentoo's close enough to what they want that there really /aren't/ a lot of distros even /close/ to suitable, let alone /more/ so. Of course, both users and distros change over time, and a lot can happen in two years, but... Then of course there's the "found your own distro" club... Something gentoo's founder, Daniel Robbins, has done more than once, now... But of course just as his current gentoo-based funtoo (and other gentoo-based distros, after all, gentoo even claims meta-distro, so gentoo-based distro fits right in!), just because you do your own thing doesn't mean you can't base on gentoo to whatever degree you want/need, as long as you maintain compatible licensing and at least semi-compatible package- management. -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman
