1i5t5.duncan at cox
Jul 17, 2012, 9:37 PM
Post #21 of 80
(682 views)
Permalink
|
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
|
signature.asc
1
