On Thu, Aug 14, 2014 at 09:56:52AM +0200, Todd Rme wrote:
The question is very ambiguous. I can't tell what it is actually suggesting be the policy practice. What does "support" imply?
First, I wrote first related mail to 'boycott systemd' thread and the poll was follow up. As I assumed that most people already ignored any new mails in that thread, I published URL outside the thread.
1. Only allow packages that support alternatives to systemd (except for ones directly targeting systemd, like systemd configuration programs), either upstream or through patches 2. Require all maintainers of packages that support alternatives to systemd to implement that support 3. Require that package maintainers accept patches to add support for alternatives to packages that don't support it 4. Require that package maintainers accept submit requests to add support for alternatives without requiring patches 5. Provide the basic infrastructure to support alternatives and let package maintainers to decide what to do for their own packages. (of course 1 implies 2-5, 2 implies 3-5, 3 implies 4-5, and 4 implies 5)
The poll was meant for simple quantifying the voices here to get the idea, what do we want. It was meant as constructive reaction to the flame. I wanted to ask first question - do you want make openSUSE less dependent on systemd, do you want to make it ready for alternatives? Do you think that it is good idea to accept patches allowing other init to work? I wanted to know whether it makes sense to invest my time into such project. I wanted to know whether it is political or technical problem. I'd go with 4 as well, best effort way, no guarantees, make openSUSE packages aware that systemd doesn't need to be always there.
And even if we go with, say, 4, does that mean that, once the submit request is accepted, the package maintainer will be requires to support the alternative himself or herself from then on?
And what is the situation now about other features? If package maintainer fails to fix an issue? I never had any guarantee...
What if a package maintainer accepts a sysv script, something changes upstream down the road, the sysv script or whatever needs to be substantially changed, and the person who submitted it has disappeared? Will the package maintainer have to rewrite the script himself or herself, or can he or she just drop it? What if the maintainer is only familiar with systemd and doesn't feel comfortable rewriting the sysv script?
I can give you only my opinion here and I expected discusion about setting rules (in case that poll result would show that people want that). Package maintainer should try to fix it by himself, if he can't he can ask for help on ML. I'd say we have here some motivated people :)
So I can't vote because I don't know what the result of my vote will actually be. I would like to think we are talking about something more 5, maybe 3 or 4 at most, but I can't tell from how the question is worded, and I strongly suspect it means different things to different people.
If you think it makes sense to create new poll, with better questions, I'd say that many people would appreciate it.
I followed the debian systemd discussion quite closely, and this was a major issue. People calling for supporting alternatives couldn't agree on what "support" actually meant, and there was about as much fighting about that as there was about whether to make systemd the default.
I really expect some discussion leading to the result, but for me as package maintainer 'support for alternative' means for me: - generic packages shouldn't count with systemd presence and should check for it's presence if they need it - for systemd as compilation time dependency we should provide packages which doesn't depend (in RPM dependency way) on systemd in case it makes sense After the discussion I'd give you better answers and even better during implementation. S_W