Re: Bug#684396: ITP: openrc -- alternative boot mechanism that manages the services, startup and shutdown of a host
Serge, I'm in the favor of having a try with OpenRC, and see what we can do, but here, your post is a bit naive at least in some cases. Let me explain why. On 09/05/2012 11:47 AM, Serge wrote: I don't see how these people help Debian if they start pushing their own solution instead of helping to improve what is already there. I thought it's obvious: * someone packages a new tool (+1 package, +1 maintainer) In this case, it's 1 package, many maintainers. * more packages in debian means more users No. Not for sure. * more users means more developers No. Not for sure. * more developers and maintainers means better debian It all depends on what these maintainers do. Anyway, I *guess* I understand your point. You afraid that *if* this new `openrc` is accepted There's no if here. I don't think anyone has the power to forbid such an upload. The problem is to decide if we should support OpenRC archive wide, and that's the debate, it's not just about uploading or not (eg: OpenRC isn't a leaf package). *and* widely used in debian That's another story. We aren't there yet, we don't even have a working package yet. *and* other package start depending on it badly *and* its maintainer will abandon it, then we may have a problem. I don't see why this would happen more than with any other stuff. So why are we even considering it? It doesn't make sense. So between two options: 1. Someone packages `openrc` and starts maintaining it. Being a maintainer he may (or may not) help other packages as well. Again, more than one person is interested in such work. But the problem is — we don't have that choice. What we really have is: 1. Someone packages `openrc` in debian and starts maintaining it. Being a maintainer he may (or may not) help other packages as well. 2. Someone goes to launchpad/github/some-private-repo and maintains `openrc` there for himself and some friends. Having such a choice I would prefer #1. And you? Help isn't enough. If we decide that OpenRC should be supported archive wide (which decision, IMO, shouldn't be discuss now), then there's thousands of packages affected. Of course, if we decide to support OpenRC, help and documentation will be mandatory. But not enough. I was trying to use some common sense (i.e. explaining that it's rude to say to people what they should do, it scares them away which means less maintainers which is bad for debian), but if you want to stick to rules, then `openrc` should be, no, it MUST be in debian repository, since at least some users asked for it and Our priorities are our users and free software, right? Also those rules don't allow anybody to decide what package I must work on, right? That's correct, anyone can work on what he wants. Though some decided to skip one step and talk about what should be the default when we are far from there. Also, the problem that has been highlighted was that if OpenRC comes to Debian, this might give a lot of work for all maintainers with packages that have init script. In fact, this is the same situation as for systemd. And we don't want to duplicate this work. I do agree with this, but I don't think we are there yet. What I asked, is to let us try, and see where it leads... I'm not saying I wouldn't trust your words, but you cannot seriously promise you will always be there to take care of OpenRC if you're the only maintainer. Sure, I can't. Anything may happen. And noone can. That's why being about choice is a good thing. If for some reason debian supported only `systemd` and tomorrow upstream announces forget systemd it won't be supported any more, we've just developed a new kernel-based init system with GNOME4 integrated into it, and being kernel-based it is lightning fast, then we'll have a problem. That's exactly the problem. We have no way to predict whatever will be upstream's decision for systemd. That's in fact, one of the reasons I'd be interested in contributing to the OpenRC packaging (I still hope to find more time with Patrick on that...). Thomas -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/504729f9.3070...@debian.org
Re: Bug#684396: ITP: openrc -- alternative boot mechanism that manages the services, startup and shutdown of a host
2012/8/31 John Paul Adrian Glaubitz wrote: Sorry for writing such a long email, but I believe that having a welcoming environment is very important for debian. It's often someone says something similar about many ITPs. I believe noone should say things like that, unless he wants to scare everybody away and have Debian forgotten and dead. Saying that you not only reduce the number of bugs in Debian, but you also reduce the number of people working on Debian, because when they hear that they just turn around and go away. I don't see how these people help Debian if they start pushing their own solution instead of helping to improve what is already there. I thought it's obvious: * someone packages a new tool (+1 package, +1 maintainer) * more packages in debian means more users * more users means more developers * more developers and maintainers means better debian Anyway, I *guess* I understand your point. You afraid that *if* this new `openrc` is accepted *and* widely used in debian *and* other package start depending on it badly *and* its maintainer will abandon it, then we may have a problem. So between two options: 1. Someone packages `openrc` and starts maintaining it. Being a maintainer he may (or may not) help other packages as well. 2. Someone joins to e.g. sysvinit and implements all features of `openrc` there you would prefer #2. I would prefer #2 myself. :) But the problem is — we don't have that choice. What we really have is: 1. Someone packages `openrc` in debian and starts maintaining it. Being a maintainer he may (or may not) help other packages as well. 2. Someone goes to launchpad/github/some-private-repo and maintains `openrc` there for himself and some friends. Having such a choice I would prefer #1. And you? Well, yes. Debian has it's policy, a social contract and the DFSG. You are certainly not allowed to do anything you want I was trying to use some common sense (i.e. explaining that it's rude to say to people what they should do, it scares them away which means less maintainers which is bad for debian), but if you want to stick to rules, then `openrc` should be, no, it MUST be in debian repository, since at least some users asked for it and Our priorities are our users and free software, right? Also those rules don't allow anybody to decide what package I must work on, right? When I come and say Hey, I want to work on openrc in debian (replace openrc with any other package), I mean what I say. Most probably I just like this particular software for some reason. And it usually never means that I also want to work on upstart/systemd/sysvinit/etc. So when you tell me don't mess around it, I won't drop openrc, I'll just drop debian. If that was really the case, how come there are so many orphaned packages in Debian? Lack of resources, maybe? Which is because of lack of developers? Which is because many new developers coming and willing to do something get unfriendly response like we don't want you to do that, we already have lots of such things in repo, work on them or go away? I'm not saying I wouldn't trust your words, but you cannot seriously promise you will always be there to take care of OpenRC if you're the only maintainer. Sure, I can't. Anything may happen. And noone can. That's why being about choice is a good thing. If for some reason debian supported only `systemd` and tomorrow upstream announces forget systemd it won't be supported any more, we've just developed a new kernel-based init system with GNOME4 integrated into it, and being kernel-based it is lightning fast, then we'll have a problem. But if we also have `openrc` and `sysvinit` then we just switch to another init system and things will mostly work. Sure, we'll still have a problem, but it would be much smaller because we initially had a choice (and `openrc` maintainer already made sure that such emergency switch won't be impossible). Debian is already very popular and successful and I don't see how OpenRC would help Debian gain more popularity. If it's already popular and successful then why there're so many orphaned packages in Debian? ;) 95% of the users don't ever interact with the init system directly, so there is no point in being able to have a choice Bad argument. :) 95% of the users don't even know what Linux is (it's just a kernel, you know) and they certainly don't interact with it directly. But it does not mean that we can forget about linux and never allow people to choose it. :) I was actually talking about Linux users, I was not referring to all people using computers in the world. Yes, that's why my analogy worked. :) You talked about all Linux users and noticed that most of them don't care about init system. So I looked at all the users and noticed that most of them don't care about Linux. :) My point is, 95% of the people who install a Debian or Ubuntu nowadays simply don't care what init system they are using as long as
Re: Bug#684396: ITP: openrc -- alternative boot mechanism that manages the services, startup and shutdown of a host
Hey Svante, On Samstag, 1. September 2012, Svante Signell wrote: Maybe you, Josselin, should step down from working on Debian. It looks like your priorities are not in line with the Debian goals and the Debian contract any longer. Whatever the consequences will be. Svante, maybe you should stop ranting on Debian mailing lists without doing anything useful and just dragging away contributors time? Sometimes not doing and saying anything is the best contribution one is able to give! Debian is not RL where standing up for ones right alone is already a useful contribution. cheers, Holger -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201209021007.10637.hol...@layer-acht.org
Re: Bug#684396: ITP: openrc -- alternative boot mechanism that manages the services, startup and shutdown of a host
On Sat, 2012-09-01 at 22:59 +0100, Steve McIntyre wrote: Svante Signell wrote: On Fri, 2012-08-31 at 19:34 +0300, Serge wrote: 2012/8/31 Josselin Mouette wrote: Linux is still not about choice? Then let's make it be about choice! ... As for Debian not being universal, this is certainly not my saying. But toy ports and toy init systems are part of what makes Debian less universal: being the universal OS doesn’t mean accepting every piece of shit, it means being able to answer every user need. Svante, you've been causing trouble for a long time now, using the excuse of being a Hurd porter. Please, don't confuse my work on Hurd with my opinions about Debian as a whole. I've bee using (and contributing to) Debian for a multitude of years now, long before starting to port packages for Hurd (and kFreeBSD). Please! I've been tempted to kill-file you for a while. But this particular message from you is so far out of line that I feel it needs a response. Calm down and apologise, or I will ask that the listmasters ban you from Debian lists. I am completely calm. And I do apologise, I am sorry for suggesting that somebody steps down from the project. That was wrong, admitted. However, for the statement above, calling everything not in line with that persons beliefs (or agenda) a piece of shit is also not nice, independent of being a DD, DM or whatever. It is not productive, only rude and showing lack of respect to other peoples work. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1346573827.5554.35.camel@x60
Re: Bug#684396: ITP: openrc -- alternative boot mechanism that manages the services, startup and shutdown of a host
Hi again, On Sonntag, 2. September 2012, Svante Signell wrote: I am completely calm. And I do apologise, I am sorry for suggesting that somebody steps down from the project. That was wrong, admitted. thanks! (a lot.) However, for the statement above, calling everything not in line with that persons beliefs (or agenda) a piece of shit is also not nice, independent of being a DD, DM or whatever. It is not productive, only rude and showing lack of respect to other peoples work. agreed. cheers, Holger -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201209021049.48799.hol...@layer-acht.org
Re: Bug#684396: ITP: openrc -- alternative boot mechanism that manages the services, startup and shutdown of a host
Le vendredi 31 août 2012 à 19:34 +0300, Serge a écrit : Yeah, one init system, one kernel, one libc, one distribution, one window manager, one OS. Looks like a windows-way. :) There’s a huge difference between being able to switch between window managers and to switch between init/kernel/libc. The former gives users a different experience, which might answer to specific needs and make the distribution better (note the “might” – I’m pretty sure it does not apply to all of the 70+ WMs we ship). Being able to choose between kernels or init systems doesn’t bring anything per se. 640kb ought to be enough for anybody. :) “Shell init scripts ought to be enough for anybody, so let’s fuck those modern init systems that use a decent format.” Linux is still not about choice? Then let's make it be about choice! What if, for once, we made it about better computing? As for Debian not being universal, this is certainly not my saying. But toy ports and toy init systems are part of what makes Debian less universal: being the universal OS doesn’t mean accepting every piece of shit, it means being able to answer every user need. So, if user needs to see something in debian repository then being universal means having it in repository. :) And what kind of users need a different init system? One good init system can answer all our needs, while four bad ones will certainly not. What if that good init system is openrc? You have to be kidding. -- .''`. Josselin Mouette : :' : `. `' `- -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1346579123.12827.7.camel@tomoe
Re: Bug#684396: ITP: openrc -- alternative boot mechanism that manages the services, startup and shutdown of a host
Le samedi 01 septembre 2012 à 12:28 +0800, Thomas Goirand a écrit : It goes from a more manageable code (for some parts, the same feature as in systemd, but with a code that is 5 times smaller), Code size is a compelling argument only with the same set of features. Which is not the case. to the fact that it may work with something else than Linux, or the fact that it supports also mdev. Supporting mdev is not a feature. Please tell us about what features you intend to bring with that. -- Josselin Mouette /\./\ pouet pouet « Sans puissance, la maîtrise n'est rien. » -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1346578639.12827.2.camel@tomoe
Re: Bug#684396: ITP: openrc -- alternative boot mechanism that manages the services, startup and shutdown of a host
Hi! Just for the record (and I might be wrong with this information, because I don't have it from a official Gentoo source): I heard from a Gentoo dev that they will switch from OpenRC to systemd, and find the possibility very funny that Gentoo switches to systemd from OpenRC and Debian switches to OpenRC from init. :-) So, it looks like Gentoo devs see value in systemd so they're consider dropping OpenRC for systemd. About the general issue: I think whoever wants to work on stuff should be able to work on it, so having OpenRC packages is not really a bad thing. So, if someone wants to do it, just do it :-) For making OpenRC default I have an other opinion: I consider systemd superior and I think making OpenRC default is just the wrong way. And I very well think we can fully support systemd and kfreebsd. I already build my packages with systemd(-logind) support in experimental and use ConsoleKit for non-Linux ports, which works exttremely well. With the new init-script-from-systemd generator, using sysvinit on non-Linux systems should also be possible, although the non-Linux porters might need to write some additional initscripts for more complicated daemons, but this should be possible to do. (It's an effort, sure, but it's worth it and a good compromise) So, I don't really see any problem anymore with systemd support. And I also have to agree with many points Josselin made (although I usually disagree with him quite often) - Choice in core infrastructure is not worth the effort just to have a choice. (This argument doesn't count for desktop components, of course) - Instead, we at Debian should provide a technically excellent OS, not a thing with many half-supported choices. Just my 2ct. Cheers, Matthias 2012/9/2 Josselin Mouette josselin.moue...@ens-lyon.org: Le samedi 01 septembre 2012 à 12:28 +0800, Thomas Goirand a écrit : It goes from a more manageable code (for some parts, the same feature as in systemd, but with a code that is 5 times smaller), Code size is a compelling argument only with the same set of features. Which is not the case. to the fact that it may work with something else than Linux, or the fact that it supports also mdev. Supporting mdev is not a feature. Please tell us about what features you intend to bring with that. -- Josselin Mouette /\./\ pouet pouet « Sans puissance, la maîtrise n'est rien. » -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1346578639.12827.2.camel@tomoe -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/caknhny8z_gawtqpzf_da7fkhosyy1yewpovh62srjwzx-wp...@mail.gmail.com
Re: Bug#684396: ITP: openrc -- alternative boot mechanism that manages the services, startup and shutdown of a host
On 09/02/12 20:43, Matthias Klumpp wrote: Hi! Just for the record (and I might be wrong with this information, because I don't have it from a official Gentoo source): I heard from a Gentoo dev that they will switch from OpenRC to systemd, No. and find the possibility very funny that Gentoo switches to systemd from OpenRC and Debian switches to OpenRC from init. :-) So, it looks like Gentoo devs see value in systemd so they're consider dropping OpenRC for systemd. There is a non-empty set of people that thinks it's a good idea. They are a small but very annoying minority that makes life hard for everyone else, so they risk getting severely ignored if they continue to cause problems. About the general issue: I think whoever wants to work on stuff should be able to work on it, so having OpenRC packages is not really a bad thing. So, if someone wants to do it, just do it :-) For making OpenRC default I have an other opinion: I consider systemd superior and I think making OpenRC default is just the wrong way. That's where opinions go apart. But right now systemd doesn't have many features (well, things I consider features) over OpenRC. And I really seriously prefer things I can fix, if I wanted magic blackbox stuff I'd be using a Mac. The added complexity of systemd is definitely not a feature at all for me. Oh well. The arguments are basically the same, it depends on your priorities. You can easily argue for or against both sides just by shifting the weight you give to things like ease of use. (Which makes most of these discussions so hilarious because we all violently agree ...) Personally I'm slowly getting tired of the forced vertical integration and change just to change things, so I'll be over there in the corner, working on obsolete technologies ;) (thanks, Lennart, you're such a funny prankster) And if you get tired of chasing a constantly changing target, well, be welcome back :) Have a nice day, Patrick -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/50435c94.6030...@gentoo.org
Re: Bug#684396: ITP: openrc -- alternative boot mechanism that manages the services, startup and shutdown of a host
Le 31 août 2012 10:06, Josselin Mouette j...@debian.org a écrit : Le vendredi 31 août 2012 à 04:18 +0300, Serge a écrit : 2012/8/10 Josselin Mouette wrote: Because being able to choose between alternatives for core features such as the init system only brings more bugs and no added value. Sorry, I don't understand this point. If it's about just adding more bugs without bringing anything good with it — sure, it's a bad idea. It is exactly what init system multiplication is about. But as long as: 1. It breaks nothing for existing installations (i.e. does not change defaults, That is already far-stretched. does not break existing custom scripts, This is even more far-stretched. even is not installed by default) 2. It has something, that is not provided by other packages, meaning, it makes someone happy. (!) Kitten pictures make me happy. Can we ship them too? I will fill an itp. Can i add you as m'y sponsor? 3. There's someone willing to maintain it and fix the bugs. That means there is someone who will pester other maintainers to “fix” their init scripts so that they work with another half-baked init implementation. PS: IMHO, saying things like Linux is not about choice and Debian is not about being universal just scares maintainers and users away from debian, and brings nothing good instead. If you’re scared by hearing that Linux is not about choice, let me say it again: Linux is not about choice. Not about choice. Choice is not inherently good. Linux is not about choice. Booh. As for Debian not being universal, this is certainly not my saying. But toy ports and toy init systems are part of what makes Debian less universal: being the universal OS doesn’t mean accepting every piece of shit, it means being able to answer every user need. Adding more choice always brings more bugs, but it does not, by far, always answer to more user needs. One good init system can answer all our needs, while four bad ones will certainly not. -- .''`. Josselin Mouette : :' : `. `' `- -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1346399420.3479.446.camel@pi0307572
Re: Bug#684396: ITP: openrc -- alternative boot mechanism that manages the services, startup and shutdown of a host
On Fri, 2012-08-31 at 19:34 +0300, Serge wrote: 2012/8/31 Josselin Mouette wrote: Linux is still not about choice? Then let's make it be about choice! As for Debian not being universal, this is certainly not my saying. But toy ports and toy init systems are part of what makes Debian less universal: being the universal OS doesn’t mean accepting every piece of shit, it means being able to answer every user need. So, if user needs to see something in debian repository then being universal means having it in repository. :) Maybe you, Josselin, should step down from working on Debian. It looks like your priorities are not in line with the Debian goals and the Debian contract any longer. Whatever the consequences will be. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1346526126.5554.19.camel@x60
Re: Bug#684396: ITP: openrc -- alternative boot mechanism that manages the services, startup and shutdown of a host
Svante Signell wrote: On Fri, 2012-08-31 at 19:34 +0300, Serge wrote: 2012/8/31 Josselin Mouette wrote: Linux is still not about choice? Then let's make it be about choice! As for Debian not being universal, this is certainly not my saying. But toy ports and toy init systems are part of what makes Debian less universal: being the universal OS doesnât mean accepting every piece of shit, it means being able to answer every user need. So, if user needs to see something in debian repository then being universal means having it in repository. :) Maybe you, Josselin, should step down from working on Debian. It looks like your priorities are not in line with the Debian goals and the Debian contract any longer. Whatever the consequences will be. Svante, you've been causing trouble for a long time now, using the excuse of being a Hurd porter. I've been tempted to kill-file you for a while. But this particular message from you is so far out of line that I feel it needs a response. Calm down and apologise, or I will ask that the listmasters ban you from Debian lists. -- Steve McIntyre, Cambridge, UK.st...@einval.com Google-bait: http://www.debian.org/CD/free-linux-cd Debian does NOT ship free CDs. Please do NOT contact the mailing lists asking us to send them to you. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/e1t7vji-0005l8...@mail.einval.com
Re: Bug#684396: ITP: openrc -- alternative boot mechanism that manages the services, startup and shutdown of a host
Le Sat, Sep 01, 2012 at 09:02:06PM +0200, Svante Signell a écrit : Maybe you, Josselin, should step down from working on Debian. It looks like your priorities are not in line with the Debian goals and the Debian contract any longer. Whatever the consequences will be. In general I am for discussing things without taboos, but if Debian had only one, I think it should be about never calling for peoples heads. We have an expulsion procedure for DDs who harm the project, and those who are not willing or not able to start this procedure should not gratuitously invite DDs to leave. And yes, this is one of the cases where it is good to underline loudly that your opinion does not matter because you are not a a member of the Debian project. And please do not answer. -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120901222031.ga11...@falafel.plessy.net
Re: Bug#684396: ITP: openrc -- alternative boot mechanism that manages the services, startup and shutdown of a host
I demand that Thomas Goirand may or may not have written... [snip] Sure, OpenRC doesn't have (yet) all the features of systemd. But because of the above, it might be worth to *at least* give it a chance. Should it have all of those features? Should it require support from other packages? (Are all of those features appropriate?) -- | _ | Darren Salt, using Debian GNU/Linux (and Android) | ( ) | | X | ASCII Ribbon campaign against HTML e-mail | / \ | http://www.asciiribbon.org/ Become a programmer and never see the world. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/52ce121a1c%lists...@moreofthesa.me.uk
Re: Bug#684396: ITP: openrc -- alternative boot mechanism that manages the services, startup and shutdown of a host
On Sep 2, 2012, at 2:36 AM, Darren Salt lists...@moreofthesa.me.uk wrote: I demand that Thomas Goirand may or may not have written... [snip] Sure, OpenRC doesn't have (yet) all the features of systemd. But because of the above, it might be worth to *at least* give it a chance. Should it have all of those features? Should it require support from other packages? (Are all of those features appropriate?) Well, the socket-based activation which allows true parallelization of the boot process as well as the replacement of the complicated and error-prone bash scripts with unit files are quite compelling in my opinion. I use systemd on my laptop with an SSD and within a kvm and have boot times down to 3 seconds. Also, systemctl and systemd-analyze are really nice. Adrian -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/213434cf-8972-4c0b-a8b6-61e01c600...@physik.fu-berlin.de
Re: Bug#684396: ITP: openrc -- alternative boot mechanism that manages the services, startup and shutdown of a host
Le vendredi 31 août 2012 à 04:18 +0300, Serge a écrit : 2012/8/10 Josselin Mouette wrote: Because being able to choose between alternatives for core features such as the init system only brings more bugs and no added value. Sorry, I don't understand this point. If it's about just adding more bugs without bringing anything good with it — sure, it's a bad idea. It is exactly what init system multiplication is about. But as long as: 1. It breaks nothing for existing installations (i.e. does not change defaults, That is already far-stretched. does not break existing custom scripts, This is even more far-stretched. even is not installed by default) 2. It has something, that is not provided by other packages, meaning, it makes someone happy. (!) Kitten pictures make me happy. Can we ship them too? 3. There's someone willing to maintain it and fix the bugs. That means there is someone who will pester other maintainers to “fix” their init scripts so that they work with another half-baked init implementation. PS: IMHO, saying things like Linux is not about choice and Debian is not about being universal just scares maintainers and users away from debian, and brings nothing good instead. If you’re scared by hearing that Linux is not about choice, let me say it again: Linux is not about choice. Not about choice. Choice is not inherently good. Linux is not about choice. Booh. As for Debian not being universal, this is certainly not my saying. But toy ports and toy init systems are part of what makes Debian less universal: being the universal OS doesn’t mean accepting every piece of shit, it means being able to answer every user need. Adding more choice always brings more bugs, but it does not, by far, always answer to more user needs. One good init system can answer all our needs, while four bad ones will certainly not. -- .''`. Josselin Mouette : :' : `. `' `- -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1346399420.3479.446.camel@pi0307572
Re: Bug#684396: ITP: openrc -- alternative boot mechanism that manages the services, startup and shutdown of a host
On Aug 31, 2012, at 9:50 AM, Josselin Mouette j...@debian.org wrote: One good init system can answer all our needs, while four bad ones will certainly not. I fully agree. The init system is a critical part of the operating system, so we shouldn't be messing around with it. Focus on the best solution, period. 95% of the users don't ever interact with the init system directly, so there is no point in being able to have a choice here as long as we make sure we're using the best solution. Please don't argue that there are also dozens of editors or window managers available, you can't compare these. Both are way more visible to the user, so it's natural to be able to choose here. While many people will disagree, I am convinced that systemd is the way to go. It is very fast, reliable and profits from modern hardware like SSDs or modern kernel features like cgroups. Yes, systemd would break the non-Linux kernels, but we could use the units-to-sysV converter to solve this problem in a painless fashion. Adrian -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/f37b32a1-c915-4f40-9908-cb2858d3c...@physik.fu-berlin.de
Re: Bug#684396: ITP: openrc -- alternative boot mechanism that manages the services, startup and shutdown of a host
2012/8/31 Josselin Mouette wrote: Because being able to choose between alternatives for core features such as the init system only brings more bugs and no added value. Sorry, I don't understand this point. If it's about just adding more bugs without bringing anything good with it — sure, it's a bad idea. It is exactly what init system multiplication is about. Yeah, one init system, one kernel, one libc, one distribution, one window manager, one OS. Looks like a windows-way. :) 640kb ought to be enough for anybody. :) But as long as: 1. It breaks nothing for existing installations (i.e. does not change defaults, That is already far-stretched. does not break existing custom scripts, This is even more far-stretched. Not sure I understand you here. even is not installed by default) 2. It has something, that is not provided by other packages, meaning, it makes someone happy. (!) Kitten pictures make me happy. Can we ship them too? Sure. I would also like to see a `kitten-wallpapers` package, if it's free (e.g. CC-BY-SA) of course. 3. There's someone willing to maintain it and fix the bugs. That means there is someone who will pester other maintainers to “fix” their init scripts so that they work with another half-baked init implementation. Not necessary. It's ITP, not RFP. That may mean that there would be someone who will send patches to other maintainers to fix their init scripts, that do not obey debian standards. If they do obey standards but still don't work under openrc then it's a bug either in debian standard or in openrc, and one of them should be fixed anyway. If you’re scared by hearing that Linux is not about choice, let me say it again: Linux is not about choice. Not about choice. Choice is not inherently good. Linux is not about choice. Booh. Hm, I use linux exactly because it's about choice. It allows me to do things that no other system does. In linux I can choose those things that suit me and use them. POSIX allows me to choose kernel and libc. XDG and X11 allows me to choose desktop environment. HTTP RFC allows me to choose the best webserver and best browser. Lots of programs in repository allows be to choose the best program that suits me. If I still miss some feature that I'd chose, GPL allows me to patch the sources and get the feature I've chosen. Do you use Linux? Why? Because it's cheap? Linux is still not about choice? Then let's make it be about choice! As for Debian not being universal, this is certainly not my saying. But toy ports and toy init systems are part of what makes Debian less universal: being the universal OS doesn’t mean accepting every piece of shit, it means being able to answer every user need. So, if user needs to see something in debian repository then being universal means having it in repository. :) Adding more choice always brings more bugs, but it does not, by far, always answer to more user needs. Agree. That's #2 of my 3 points. If nobody really needs it, meaning, if nobody asked for it, and it does not make anyone happy, there's no need to spend time on it. Does openrc make anyone happy? But if it has some advantages over existing systems, it at least deserves the right to be chosen by those who needs those advantages. One good init system can answer all our needs, while four bad ones will certainly not. What if that good init system is openrc? -- Serge -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAOVenEr4-5q=sb8unrqo3gwfute7xumih_0x8dbqknwnxzw...@mail.gmail.com
Re: Bug#684396: ITP: openrc -- alternative boot mechanism that manages the services, startup and shutdown of a host
2012/8/31 John Paul Adrian Glaubitz wrote: The init system is a critical part of the operating system, so we shouldn't be messing around with it. Focus on the best solution, period. It's often someone says something similar about many ITPs. I believe noone should say things like that, unless he wants to scare everybody away and have Debian forgotten and dead. Saying that you not only reduce the number of bugs in Debian, but you also reduce the number of people working on Debian, because when they hear that they just turn around and go away. If I was an employee of Debian Inc, and I was paid to spend my 40 hours/week to my company, then you could tell me don't mess around openrc, focus on upstart, that's a chief's order (that may work for RedHat). But Debian does not pay me, and noone can tell me what to do. When I come and say Hey, I want to work on openrc in debian (replace openrc with any other package), I mean what I say. Most probably I just like this particular software for some reason. And it usually never means that I also want to work on upstart/systemd/sysvinit/etc. So when you tell me don't mess around it, I won't drop openrc, I'll just drop debian. You can only politely ask Please, before continuing to work on openrc, look at other init systems, maybe you will find there what you need, or maybe it would be easier for you to implement the features you need in those systems instead of maintaining a new init system on your own. But you can't say me what should I do, because I'll just go to Arch/Gentoo, that are not as hostile. If we want debian to be a successful and popular distribution, we should welcome everybody, does not matter what they want to work on. That should bring more people to debian. And we want more people to work on debian, don't we? We must help them to work on it, and just hope, that some day they will also help us to work on our projects too. That's IMHO, of course. 95% of the users don't ever interact with the init system directly, so there is no point in being able to have a choice Bad argument. :) 95% of the users don't even know what Linux is (it's just a kernel, you know) and they certainly don't interact with it directly. But it does not mean that we can forget about linux and never allow people to choose it. :) -- Serge -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAOVenEpJT63OYbPRtzZcDyk7XkZhi=1vn8sd0tnqd7gv9pf...@mail.gmail.com
Re: Bug#684396: ITP: openrc -- alternative boot mechanism that manages the services, startup and shutdown of a host
On 08/31/2012 03:50 PM, Josselin Mouette wrote: That means there is someone who will pester other maintainers to “fix” their init scripts so that they work with another half-baked init implementation. Ah... And that will not happen with systemd? Come on, we all know that we will have to change stuff archive wide, whatever decision we take. But toy ports and toy init systems are part of what makes Debian less universal: being the universal OS doesn’t mean accepting every piece of shit I'm not sure what you call every piece of shit, I just hope this isn't OpenRC or toy ports that you are talking about here. One good init system can answer all our needs, while four bad ones will certainly not. I guess this depends what you call good. For me, something that imposes on us decisions that are forcing: - move to /usr and no chances to change this - configuration files outside /etc just because of internal limitations of RPM, which goes against our policy manual - incompatibility with anything else than Linux, and not even a chance that upstream accept patches to change this Add this a hostile upstream, and it becomes more a threat than an anything else, even if it's technically better and with more features than any other init system. Sure, OpenRC doesn't have (yet) all the features of systemd. But because of the above, it might be worth to *at least* give it a chance. Thomas -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/504108ed.3030...@debian.org
Re: Bug#684396: ITP: openrc -- alternative boot mechanism that manages the services, startup and shutdown of a host
On Fri, Aug 31, 2012 at 08:28:27PM +0300, Serge wrote: It's often someone says something similar about many ITPs. I believe noone should say things like that, unless he wants to scare everybody away and have Debian forgotten and dead. Saying that you not only reduce the number of bugs in Debian, but you also reduce the number of people working on Debian, because when they hear that they just turn around and go away. I don't see how these people help Debian if they start pushing their own solution instead of helping to improve what is already there. If I was an employee of Debian Inc, and I was paid to spend my 40 hours/week to my company, then you could tell me don't mess around openrc, focus on upstart, that's a chief's order (that may work for RedHat). But Debian does not pay me, and noone can tell me what to do. Well, yes. Debian has it's policy, a social contract and the DFSG. You are certainly not allowed to do anything you want unless you start your own blend of Debian by forking it. When I come and say Hey, I want to work on openrc in debian (replace openrc with any other package), I mean what I say. Most probably I just like this particular software for some reason. And it usually never means that I also want to work on upstart/systemd/sysvinit/etc. So when you tell me don't mess around it, I won't drop openrc, I'll just drop debian. If that was really the case, how come there are so many orphaned packages in Debian? I'm not saying I wouldn't trust your words, but you cannot seriously promise you will always be there to take care of OpenRC if you're the only maintainer. You can only politely ask Please, before continuing to work on openrc, look at other init systems, maybe you will find there what you need, or maybe it would be easier for you to implement the features you need in those systems instead of maintaining a new init system on your own. But you can't say me what should I do, because I'll just go to Arch/Gentoo, that are not as hostile. I don't understand your rage. Debian has always been strict about its policies, this isn't really new. As Josselin already pointed out, there are rules and you are not allowed to do what you want. If you don't agree with that, it's fine. But please don't force this onto Debian. If we want debian to be a successful and popular distribution, we should welcome everybody, does not matter what they want to work on. That should bring more people to debian. And we want more people to work on debian, don't we? We must help them to work on it, and just hope, that some day they will also help us to work on our projects too. That's IMHO, of course. Debian is already very popular and successful and I don't see how OpenRC would help Debian gain more popularity. 95% of the users don't ever interact with the init system directly, so there is no point in being able to have a choice Bad argument. :) 95% of the users don't even know what Linux is (it's just a kernel, you know) and they certainly don't interact with it directly. But it does not mean that we can forget about linux and never allow people to choose it. :) I was actually talking about Linux users, I was not referring to all people using computers in the world. My point is, 95% of the people who install a Debian or Ubuntu nowadays simply don't care what init system they are using as long as the code is mature and reliable. Your arguments aren't - at least - convincing me why we should have OpenRC in Debian. If you really want to convince me and others being sceptical about OpenRC, then you should list a number of arguments why OpenRC is actually a good alternative to the existing init systems in Debian. There should be at least some compelling technical arguments for OpenRC. Saying that you don't like systemd or its upstream author doesn't count, because this isn't something which affects end users. A valid argument in favor of OpenRC and against systemd is certainly that the former is platform-agnostic. But I think that the non-Linux ports of Debian aren't (yet) important enough to weigh strong enough in such decisions. Cheers, Adrian -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120831200609.ga16...@physik.fu-berlin.de
Re: Bug#684396: ITP: openrc -- alternative boot mechanism that manages the services, startup and shutdown of a host
On 09/01/2012 04:06 AM, John Paul Adrian Glaubitz wrote: There should be at least some compelling technical arguments for OpenRC. There are, and they have been listed already. It goes from a more manageable code (for some parts, the same feature as in systemd, but with a code that is 5 times smaller), to the fact that it may work with something else than Linux, or the fact that it supports also mdev. These are very interesting features. The fact that upstream is also willing to help is also very good. It feels like repeating... Thomas -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/50418ef1.1060...@debian.org
Re: Bug#684396: ITP: openrc -- alternative boot mechanism that manages the services, startup and shutdown of a host
On 09/01/12 04:06, John Paul Adrian Glaubitz wrote: On Fri, Aug 31, 2012 at 08:28:27PM +0300, Serge wrote: It's often someone says something similar about many ITPs. I believe noone should say things like that, unless he wants to scare everybody away and have Debian forgotten and dead. Saying that you not only reduce the number of bugs in Debian, but you also reduce the number of people working on Debian, because when they hear that they just turn around and go away. I don't see how these people help Debian if they start pushing their own solution instead of helping to improve what is already there. Sometimes those two are the same thing ... -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/504198a7.4010...@gentoo.org
Re: Bug#684396: ITP: openrc -- alternative boot mechanism that manages the services, startup and shutdown of a host
2012/8/10 Josselin Mouette wrote: Please explain why adding another sysv-rc drop-in replacements cripples the Linux port. Because being able to choose between alternatives for core features such as the init system only brings more bugs and no added value. Sorry, I don't understand this point. If it's about just adding more bugs without bringing anything good with it — sure, it's a bad idea. But as long as: 1. It breaks nothing for existing installations (i.e. does not change defaults, does not break existing custom scripts, even is not installed by default) 2. It has something, that is not provided by other packages, meaning, it makes someone happy. (!) 3. There's someone willing to maintain it and fix the bugs. As long as all 3 points are true — why not? ;) I would apply these points to every ITP, not just openrc. PS: IMHO, saying things like Linux is not about choice and Debian is not about being universal just scares maintainers and users away from debian, and brings nothing good instead. If people become happy fixing bugs in their own toy ports — let them work! More happy people is good for debian, isn't it? -- Serge -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAOVenEp82g82SZH2hZ2gZK43jBCu7=-tm28oqj3aek8req5...@mail.gmail.com
Re: Bug#684396: ITP: openrc -- alternative boot mechanism that manages the services, startup and shutdown of a host
On 08/19/2012 07:30 PM, Russ Allbery wrote: Marc Haber mh+debian-de...@zugschlus.de writes: Amen. I find it derogatory towards the people spending months of their private time to make exotic ports work to call their work toy ports. I am seriously thinking about a GR explicitly endorsing the work on more exotic ports to stop this derogatory, impolite and contraproductive behavior. I'd second it, in exactly that hope. Me too. -- Bernd ZeimetzDebian GNU/Linux Developer http://bzed.dehttp://www.debian.org GPG Fingerprint: ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/503e0897.1020...@bzed.de
Re: Bug#684396: ITP: openrc -- alternative boot mechanism that manages the services, startup and shutdown of a host
On 08/10/2012 10:55 AM, Marco d'Itri wrote: On Aug 10, Philip Hands p...@hands.com wrote: Now that they've done the bulk of the effort, do you really expect them to simply discard their work because you tell them to? I really do not care about what the openrc developers will do, my interest is in what Debian developers will do. No, Your interest is only what you like. And your second interest is trying to force other people to share your opinion. So, please tell us about the corrosive harm that you think is going to result from this being allowed into the archive (in detail, with references), or let them get on with it. There are two main issues with trying to support multiple init systems. The first one is the time needed to do it. If the project decides that this is the way to go, you'll have to live with it. So far I can't see how using openrc wastes time at all so far. Wasting my time are all the systemd fanboys who want their please-make-that-compatible-with-systemd patches applied. The second and more important one is being limited by the features of the less capable implementation, which would be a disgrace. So far I can see nothing that would make me feel limited by openrc. -- Bernd ZeimetzDebian GNU/Linux Developer http://bzed.dehttp://www.debian.org GPG Fingerprint: ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/503cba72.8040...@bzed.de
Re: Bug#684396: ITP: openrc -- alternative boot mechanism that manages the services, startup and shutdown of a host
On 08/10/2012 09:25 AM, Martin Wuertele wrote: * Josselin Mouette j...@debian.org [2012-08-09 23:15]: And no, choice between multiple broken implementation is NOT added value. Linux is not about choice. Luckily that is not everyones opinion. Strong ack. I'm using open source software because I want to to be able to choose. -- Bernd ZeimetzDebian GNU/Linux Developer http://bzed.dehttp://www.debian.org GPG Fingerprint: ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/503cbabd.4080...@bzed.de
Re: Bug#684396: ITP: openrc -- alternative boot mechanism that manages the services, startup and shutdown of a host
On Mon, Aug 20, 2012 at 12:37:32PM -0700, Russ Allbery wrote: We don't have a particularly good way of handling this situation right now other than one-off work on each package that may need to be treated unusually. It's a bit difficult for the maintainer to determine the implications for the dependency graph, and there isn't any good way to exclude all packages in a particular class from a particular architecture. It's not that hard. Something like «dak rm -n -R -b -a s390 -s unstable pciutils libpci3» on ries (the DD-accessible ftp-master mirror). However this does not recurse, so you need to add the resulting packages to the RM or look if those listed can be fixed by dropping the Build-Dependency. We have some architectures where I really doubt that anyone is using them for anything other than a server (s390, for instance), and (modulo cases where it makes sense to run such software as part of a remote session on a shared-user system) [...] People once said exactly that as a use case. However I'm unsure who the users of Debian s390(x) really are. And I don't know if the largest user (still?) does that. I imagine that it would work to use a mainframe as a thin client host in any case. Some blacklisting happens in P-a-s and some through BD-Uninstallable by Build-Depending on something that does not exist on that architecture. Kind regards Philipp Kern signature.asc Description: Digital signature
Re: Bug#684396: ITP: openrc -- alternative boot mechanism that manages the services, startup and shutdown of a host
Philipp Kern pk...@debian.org writes: On Mon, Aug 20, 2012 at 10:32:07AM +0200, Gergely Nagy wrote: If neither upstream, nor porters care about a particular package, that means there are very little use of having it on that port, and one should consider changing the Architecture line to exclude the failing port. That's about a minute of work + an RM request for that port: another minute or two. I don't think this is a bad thing, or something *any* maintainer should find troublesome. That's untrue. An RM request might have far reaching consequences. It can mean that another package gets uninstallable, which then requires editing its Build-Dependency list if it can be built on the target architecture without it. And that might trickle down to many packages. AFAIK that's basically the approach the GNOME maintainers use and it means that despite the package not being tested (and possibly used) at all on those architectures, you need to carry on a lot of excludes for that port and possibly cripple the platform. Indeed, there are parts of the archive that are far more complicated than the rest, where an RM request has far reaching consequences. I'd like to believe that is the exception, though. -- |8] -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87mx1oej3u.fsf@algernon.balabit
Re: Bug#684396: ITP: openrc -- alternative boot mechanism that manages the services, startup and shutdown of a host
* Ben Hutchings b...@decadent.org.uk [120820 20:21]: I don't think we should expect other developers to spend any large amount of time to help with our own pet projects, except in so far as they benefit 'our users and the free software community', which I take to mean collective interests (i.e. numbers matter). Right now, most package maintainers can provide more benefit to more users by working on bugs that affect x86, than by spending that same time investigating even the most serious problems on some other architecture. Of course they should not stand in the way of porters and should be ready to answer questions and apply reasonable patches. While I agree with the first part (people doing their pet stuff should not distract others), I see the roles afterwards differently, though: Most software working only on x86 is simply some pet project, with code so broken that any newer compiler version will likely break it[1]. And it is porters that waste their time fixing bugs in toy software, most of the time having to cope with code so broken it is a miracle it worked even on any compiler version on x86[2]. There is some minor number of port specific issues (though they are of course quite frustrating as one as maintainer of a package can do little in this case), but in my experience the numbers are similar as with alleged bugs of compiler misoptimising code: in over 95% of cases it is a bug in the program instead. More often than not a serious bug in another architecture is just a case of a serious bug that does not yet show up on the more common architectures or only very seldom, but lurking in the dark, waiting till it can also hit your more users later if ignored now. Bernhard R. Link [1] As a C program can give very little information, almost all optimisations involve some step of the rules forbid this behavior as it would not work on some obscure architecture, so I can assume that behavior is not the intended, so I can optimize for the other case. [2] Well, it's not really a miracle, but observation bias: Only that buggy code that 'luckily' did not cause breakage on previous compiler versions on x86 (or on sparc if you look at 15 years old code) has survived testing by the original authors, so you only meet those, unlikely as they are. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120821093243.ga2...@client.brlink.eu
Re: Bug#684396: ITP: openrc -- alternative boot mechanism that manages the services, startup and shutdown of a host
Charles Plessy ple...@debian.org writes: Le Sun, Aug 19, 2012 at 11:13:23PM +0200, Gergely Nagy a écrit : Michael Biebl bi...@debian.org writes: If those ports need a GR to silence any criticsm regarding those ports, then something is going seriously wrong. I've yet to see said criticism. In the absense of regression tests, we distribute thousands of packages that nobody knows if they work or not, because nobody ever used them. That's not a criticism against the port, but a criticism against packages not having tests. It is by no means the fault of the port that packages are not properly tested, as that applies to every single one of them. Then one day they happen to fail to build, or regression tests are implemented and crash, and suddenly the maintainer has to take care of development issues that are not supported upstream nor by the porters. If neither upstream, nor porters care about a particular package, that means there are very little use of having it on that port, and one should consider changing the Architecture line to exclude the failing port. That's about a minute of work + an RM request for that port: another minute or two. I don't think this is a bad thing, or something *any* maintainer should find troublesome. We need to take this specialisation into account, be proud of what our ports bring to their users, and be more open-minded about ignoring combinations of softwares and architectures that were never designed to work together. Indeed. There is a simple heuristic to detect such cases, it is when the only help a maintainer receives is guidance on how to ask for a login on the porter box and fix the package himself. If neither upstream, the users and the porters care, then we need to provide to the maintainer some ways to ignore issues without having to spend time on requesting architecture-specific archive removals, etc. What's wrong with requesting arch-specific removals? It doesn't take a lot of time, perhaps at the other end. But then, such removal requests are - judging by a quick glimpse of bugs-dist - aren't all that common to warrant special treatment of any kind. -- |8] -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87fw7im0ag@luthien.mhp
Re: Bug#684396: ITP: openrc -- alternative boot mechanism that manages the services, startup and shutdown of a host
On Mon, Aug 20, 2012 at 10:32:07AM +0200, Gergely Nagy wrote: If neither upstream, nor porters care about a particular package, that means there are very little use of having it on that port, and one should consider changing the Architecture line to exclude the failing port. That's about a minute of work + an RM request for that port: another minute or two. I don't think this is a bad thing, or something *any* maintainer should find troublesome. That's untrue. An RM request might have far reaching consequences. It can mean that another package gets uninstallable, which then requires editing its Build-Dependency list if it can be built on the target architecture without it. And that might trickle down to many packages. AFAIK that's basically the approach the GNOME maintainers use and it means that despite the package not being tested (and possibly used) at all on those architectures, you need to carry on a lot of excludes for that port and possibly cripple the platform. Of course, if GNOME is unused one could just remove it completely from those ports, but I doubt that your approach of it's just a minute of work to RM it is welcomed. (Well, the maintainers would probably like it, as long as there won't be bugs claiming that you have to support that port because it's a Debian port in testing.) Kind regards Philipp Kern signature.asc Description: Digital signature
Re: Bug#684396: ITP: openrc -- alternative boot mechanism that manages the services, startup and shutdown of a host
Le samedi 18 août 2012 à 17:40 +0200, Marc Haber a écrit : On Fri, 10 Aug 2012 00:50:43 +0200, Josselin Mouette j...@debian.org wrote: Please explain again why we should cripple the Linux port for the sake of toy ports? Because Debian prides itself in being Universal regarding ports and architectures. It is a real pity that we still have members who didn't understand this. Silly me. I thought Debian prided itself in being universal regarding usage. Of course we should prioritize universality in terms of technical details, not in terms of being useful. I stand corrected. -- .''`. Josselin Mouette : :' : `. `' `- -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1345459275.5401.33.camel@tomoyo
Re: Bug#684396: ITP: openrc -- alternative boot mechanism that manages the services, startup and shutdown of a host
On Mon, Aug 20, 2012 at 12:41:15PM +0200, Josselin Mouette wrote: Le samedi 18 août 2012 à 17:40 +0200, Marc Haber a écrit : On Fri, 10 Aug 2012 00:50:43 +0200, Josselin Mouette j...@debian.org wrote: Please explain again why we should cripple the Linux port for the sake of toy ports? Because Debian prides itself in being Universal regarding ports and architectures. It is a real pity that we still have members who didn't understand this. Silly me. I thought Debian prided itself in being universal regarding usage. Of course we should prioritize universality in terms of technical details, not in terms of being useful. I stand corrected. Quite. I tend to assume that most people working on Debian do so either because it's fun or, less commonly, because they are paid to do so (or sometimes both). Some area of work that is intellectually or materially rewarding for one developer may not be for others. I don't think we should expect other developers to spend any large amount of time to help with our own pet projects, except in so far as they benefit 'our users and the free software community', which I take to mean collective interests (i.e. numbers matter). Right now, most package maintainers can provide more benefit to more users by working on bugs that affect x86, than by spending that same time investigating even the most serious problems on some other architecture. Of course they should not stand in the way of porters and should be ready to answer questions and apply reasonable patches. Ben. -- Ben Hutchings We get into the habit of living before acquiring the habit of thinking. - Albert Camus -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120820171257.gg29...@decadent.org.uk
Re: Bug#684396: ITP: openrc -- alternative boot mechanism that manages the services, startup and shutdown of a host
Philipp Kern pk...@debian.org writes: Of course, if GNOME is unused one could just remove it completely from those ports, but I doubt that your approach of it's just a minute of work to RM it is welcomed. (Well, the maintainers would probably like it, as long as there won't be bugs claiming that you have to support that port because it's a Debian port in testing.) It probably works okay for the kind of packages that Charles is primarily talking about, though (scientific computing packages written by scientists rather than software developers that have probably never been run upstream on a non-Intel processor and are usually leaf packages or, if not leaf, only depended on by other packages with a similar profile). We don't have a particularly good way of handling this situation right now other than one-off work on each package that may need to be treated unusually. It's a bit difficult for the maintainer to determine the implications for the dependency graph, and there isn't any good way to exclude all packages in a particular class from a particular architecture. We have some architectures where I really doubt that anyone is using them for anything other than a server (s390, for instance), and (modulo cases where it makes sense to run such software as part of a remote session on a shared-user system) we don't have a good way of easily flagging local desktop software that probably doesn't make a lot of sense in that context. That said, we do get value from porting that software to all architectures, even if it's unlikely anyone would want to run it there. Several of those architectures have unusual features that have later turned up in mainstream architectures, and the earlier porting efforts have given Debian a huge leg up. For example, our 64-bit porting was mostly already done by the time that amd64 became a popular architecture, thanks to other architectures that people would have considered obscure. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87393huzgj@windlord.stanford.edu
Re: Bug#684396: ITP: openrc -- alternative boot mechanism that manages the services, startup and shutdown of a host
Le lundi 20 août 2012 à 18:12 +0100, Ben Hutchings a écrit : I don't think we should expect other developers to spend any large amount of time to help with our own pet projects, except in so far as they benefit 'our users and the free software community', which I take to mean collective interests (i.e. numbers matter). Right now, most package maintainers can provide more benefit to more users by working on bugs that affect x86, than by spending that same time investigating even the most serious problems on some other architecture. Of course they should not stand in the way of porters and should be ready to answer questions and apply reasonable patches. I say amen to all of that. Unfortunately, we’re soon reaching the point where supporting some architectures will be way beyond “reasonable patches”. -- .''`. Josselin Mouette : :' : `. `' `- -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1345503028.5401.40.camel@tomoyo
Re: Bug#684396: ITP: openrc -- alternative boot mechanism that manages the services, startup and shutdown of a host
On Sat, 18 Aug 2012 19:47:43 +0200, m...@linux.it (Marco d'Itri) wrote: On Aug 18, Marc Haber mh+debian-de...@zugschlus.de wrote: Because Debian prides itself in being Universal regarding ports and architectures. Does it? Who said so? We. In the same way you say we when you claim to be talking about Debian and trying to make your personal opinion sounds like it was broad consensus. Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber |Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom | http://www.zugschlus.de/ Nordisch by Nature | Lt. Worf, TNG Rightful Heir | Fon: *49 621 72739834 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/e1t2zhw-0002ac...@swivel.zugschlus.de
Re: Bug#684396: ITP: openrc -- alternative boot mechanism that manages the services, startup and shutdown of a host
On Sun, 19 Aug 2012 02:14:22 +0800, Aron Xu happyaron...@gmail.com wrote: For yourself, they might be toy ports, but please don't speak on behalf of others from time to time when nobody authorized you to do so. I'm not using those ports everyday but I respect their passion and efforts. Amen. I find it derogatory towards the people spending months of their private time to make exotic ports work to call their work toy ports. I am seriously thinking about a GR explicitly endorsing the work on more exotic ports to stop this derogatory, impolite and contraproductive behavior. Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber |Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom | http://www.zugschlus.de/ Nordisch by Nature | Lt. Worf, TNG Rightful Heir | Fon: *49 621 72739834 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/e1t2zj7-0002bw...@swivel.zugschlus.de
Re: Bug#684396: ITP: openrc -- alternative boot mechanism that manages the services, startup and shutdown of a host
On 12942 March 1977, Marco d'Itri wrote: Because Debian prides itself in being Universal regarding ports and architectures. Does it? Who said so? But even if this were true, it does not automatically justify dumbing down the OS which people in the real world use for the sake of toy ports. There are no toy ports. Just some (unfortunately) DDs who don't get it. -- bye, Joerg Sahneschnitter Aquariophile: welches debian/ welche xfree version? Aquariophile woody Aquariophile Xfree version 86 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/874nnzl1ec@gkar.ganneff.de
Re: Bug#684396: ITP: openrc -- alternative boot mechanism that manages the services, startup and shutdown of a host
Marc Haber wrote: Amen. I find it derogatory towards the people spending months of their private time to make exotic ports work to call their work toy ports. There are people who use their time doing things like hopping across a continent on one foot. That is a lot of work, but it's not particularly useful to anyone. Amount of work alone does not imply something deserves support. At best it's harmless; if the people doing it insist others help them, or otherwise hinder others doing more useful things, then it's contemptible. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1345375164.1896.23.camel@glyph.nonexistent.invalid
Re: Bug#684396: ITP: openrc -- alternative boot mechanism that manages the services, startup and shutdown of a host
Marc Haber mh+debian-de...@zugschlus.de writes: Amen. I find it derogatory towards the people spending months of their private time to make exotic ports work to call their work toy ports. I am seriously thinking about a GR explicitly endorsing the work on more exotic ports to stop this derogatory, impolite and contraproductive behavior. I'd second it, in exactly that hope. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87mx1qeqm2@windlord.stanford.edu
Re: Bug#684396: ITP: openrc -- alternative boot mechanism that manages the services, startup and shutdown of a host
On 19.08.2012 19:30, Russ Allbery wrote: Marc Haber mh+debian-de...@zugschlus.de writes: Amen. I find it derogatory towards the people spending months of their private time to make exotic ports work to call their work toy ports. I am seriously thinking about a GR explicitly endorsing the work on more exotic ports to stop this derogatory, impolite and contraproductive behavior. I'd second it, in exactly that hope. Sorry, but I think this would be non-sense. Either the exotic ports (as Marc called them) prove themselves to be useful and valuable based on their technical merits or they don't. If those ports need a GR to silence any criticsm regarding those ports, then something is going seriously wrong. Michael -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Re: Bug#684396: ITP: openrc -- alternative boot mechanism that manages the services, startup and shutdown of a host
Michael Biebl bi...@debian.org writes: If those ports need a GR to silence any criticsm regarding those ports, then something is going seriously wrong. I've yet to see said criticism. -- |8] -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/874nnyio0c@luthien.mhp
Re: Bug#684396: ITP: openrc -- alternative boot mechanism that manages the services, startup and shutdown of a host
Le Sun, Aug 19, 2012 at 11:13:23PM +0200, Gergely Nagy a écrit : Michael Biebl bi...@debian.org writes: If those ports need a GR to silence any criticsm regarding those ports, then something is going seriously wrong. I've yet to see said criticism. In the absense of regression tests, we distribute thousands of packages that nobody knows if they work or not, because nobody ever used them. Then one day they happen to fail to build, or regression tests are implemented and crash, and suddenly the maintainer has to take care of development issues that are not supported upstream nor by the porters. Both are dedicating their work to areas where they know that users and themselves will directly benefit from their efforts. Have you seen mobile phones running with Itanium processors, or was the Higgs boson discoverd by analysing particule accelerator output with a farm of MIPS boards ? No. We need to take this specialisation into account, be proud of what our ports bring to their users, and be more open-minded about ignoring combinations of softwares and architectures that were never designed to work together. There is a simple heuristic to detect such cases, it is when the only help a maintainer receives is guidance on how to ask for a login on the porter box and fix the package himself. If neither upstream, the users and the porters care, then we need to provide to the maintainer some ways to ignore issues without having to spend time on requesting architecture-specific archive removals, etc. Have a nice day, -- Charles Plessy Debian Med packaging team, http://www.debian.org/devel/debian-med Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120819230023.ga6...@falafel.plessy.net
Re: Bug#684396: ITP: openrc -- alternative boot mechanism that manages the services, startup and shutdown of a host
On Fri, 10 Aug 2012 00:50:43 +0200, Josselin Mouette j...@debian.org wrote: Le jeudi 09 août 2012 à 23:53 +0200, Carlos Alberto Lopez Perez a écrit : What about Debian kFreeBSD and Hurd? AFAIK systemd needs a linux kernel to work. Please explain again why we should cripple the Linux port for the sake of toy ports? Because Debian prides itself in being Universal regarding ports and architectures. It is a real pity that we still have members who didn't understand this. Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber |Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom | http://www.zugschlus.de/ Nordisch by Nature | Lt. Worf, TNG Rightful Heir | Fon: *49 621 72739834 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/e1t2l8g-000224...@swivel.zugschlus.de
Re: Bug#684396: ITP: openrc -- alternative boot mechanism that manages the services, startup and shutdown of a host
On Aug 18, Marc Haber mh+debian-de...@zugschlus.de wrote: Because Debian prides itself in being Universal regarding ports and architectures. Does it? Who said so? But even if this were true, it does not automatically justify dumbing down the OS which people in the real world use for the sake of toy ports. -- ciao, Marco signature.asc Description: Digital signature
Re: Bug#684396: ITP: openrc -- alternative boot mechanism that manages the services, startup and shutdown of a host
On Sun, Aug 19, 2012 at 1:47 AM, Marco d'Itri m...@linux.it wrote: On Aug 18, Marc Haber mh+debian-de...@zugschlus.de wrote: Because Debian prides itself in being Universal regarding ports and architectures. Does it? Who said so? But even if this were true, it does not automatically justify dumbing down the OS which people in the real world use for the sake of toy ports. For yourself, they might be toy ports, but please don't speak on behalf of others from time to time when nobody authorized you to do so. I'm not using those ports everyday but I respect their passion and efforts. -- Regards, Aron Xu -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAMr=8w7_8b3CeCjceUxYB27KRKrJ_Su_SHrqDv7sCq=smkn...@mail.gmail.com
Re: Bug#684396: ITP: openrc -- alternative boot mechanism that manages the services, startup and shutdown of a host
On Aug 18, Aron Xu happyaron...@gmail.com wrote: For yourself, they might be toy ports, but please don't speak on behalf of others from time to time when nobody authorized you to do so. I am not, but I understand that arguing about this is much easier than arguing that incomplete ports used by a few dozen people are not toys. This does not mean that toys are a bad thing, but most other people[1] have different priorities. I'm not using those ports everyday but I respect their passion and efforts. I respect people wasting their time in any way they like, as long as they also do not try to cripple my favourite OS. [1] Again not speaking on behalf of others, just applying common sense -- ciao, Marco signature.asc Description: Digital signature
Re: Bug#684396: ITP: openrc -- alternative boot mechanism that manages the services, startup and shutdown of a host
* Josselin Mouette j...@debian.org [2012-08-10 13:27]: Le vendredi 10 août 2012 à 11:56 +0200, Martin Wuertele a écrit : That we do no longer have glibc in the archive and we had a transition to eglibc was an understandable maintainer decision. glibc/eglibc is not comparable to the other alternatives, the differences are extremely tiny. How is core funcionality defined anyways? If network is considered a core function and then we have net-tools and iprout, ifupdown, network-manager, wicd, ethtool, mii-diag, and users do have a choice. And this leads to poor user experience because none of these alternatives offers everything we expect from the networking system. This is true, makes one wonder though why only the gnome maintainers try to force one specific of these alternatives on users. We do not yet have mdev in the archive but I hope that changes with the next release. I can’t wait to see the brokenness it will bring. Can't be worse than the initial ~90 releases of udev (including non-direct kernel upgrades). Yours Martin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120813071613.gk10...@anguilla.debian.or.at
Re: Bug#684396: ITP: openrc -- alternative boot mechanism that manages the services, startup and shutdown of a host
Hi Marco, Marco d'Itri m...@linux.it writes: On Aug 10, Roger Leigh rle...@codelibre.net wrote: In the case of OpenRC, it has the potential to be a drop-in replacement for sysv-rc (note that it uses base sysvinit still underneath that). So do the other init systems. The point is what they can do which sysvinit (and openrc) cannot. You may have noticed that despite your incessant attempts to shout this effort down, they went ahead and did it anyway. Now that they've done the bulk of the effort, do you really expect them to simply discard their work because you tell them to? You might not like it, and you might even think they've been wasting their time, but unless you can come up with a demonstration that allowing this in will cause actual damage to the distribution you might as well shut up. As a largely disinterested observer, it seems that this might at least provide a route to being able to provide enough support of the the features that make the systemd/upstart folk dizzy with excitement, such that non-linux platforms don't end up acting as a blocker for one of those two to be adopted for linux, while OpenRC covers non-linux enough so that init-agnostic start-up scripts can work anywhere. If it only results in some more effort being applied to coming up with that agnostic solution, then the rest of us can then get on with life while the upstart and systemd folk take chunks out of one another for a decade or so. So, please tell us about the corrosive harm that you think is going to result from this being allowed into the archive (in detail, with references), or let them get on with it. Cheers, Phil. -- |)| Philip Hands [+44 (0)20 8530 9560]http://www.hands.com/ |-| HANDS.COM Ltd.http://www.uk.debian.org/ |(| 10 Onslow Gardens, South Woodford, London E18 1NE ENGLAND pgpgEFIgWdDXc.pgp Description: PGP signature
Re: Bug#684396: ITP: openrc -- alternative boot mechanism that manages the services, startup and shutdown of a host
* Josselin Mouette j...@debian.org [2012-08-10 01:06]: Le jeudi 09 août 2012 à 23:53 +0200, Carlos Alberto Lopez Perez a écrit : What about Debian kFreeBSD and Hurd? AFAIK systemd needs a linux kernel to work. Please explain again why we should cripple the Linux port for the sake of toy ports? Please explain why adding another sysv-rc drop-in replacements cripples the Linux port. Thanks, Martin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120810072322.gc10...@anguilla.debian.or.at
Re: Bug#684396: ITP: openrc -- alternative boot mechanism that manages the services, startup and shutdown of a host
* Josselin Mouette j...@debian.org [2012-08-09 23:15]: And no, choice between multiple broken implementation is NOT added value. Linux is not about choice. Luckily that is not everyones opinion. Martin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120810072558.gd10...@anguilla.debian.or.at
Re: Bug#684396: ITP: openrc -- alternative boot mechanism that manages the services, startup and shutdown of a host
Le vendredi 10 août 2012 à 09:23 +0200, Martin Wuertele a écrit : Please explain why adding another sysv-rc drop-in replacements cripples the Linux port. Because being able to choose between alternatives for core features such as the init system only brings more bugs and no added value. http://www.redhat.com/archives/rhl-devel-list/2008-January/msg00861.html -- .''`. Josselin Mouette : :' : `. `' `- -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1344585409.4874.20.camel@tomoe
Re: Bug#684396: ITP: openrc -- alternative boot mechanism that manages the services, startup and shutdown of a host
* Josselin Mouette j...@debian.org [2012-08-10 10:12]: Le vendredi 10 août 2012 à 09:23 +0200, Martin Wuertele a écrit : Please explain why adding another sysv-rc drop-in replacements cripples the Linux port. Because being able to choose between alternatives for core features such as the init system only brings more bugs and no added value. http://www.redhat.com/archives/rhl-devel-list/2008-January/msg00861.html And that really explains why there is a choice for core functions like kernel event handler: udevd, hotplug2, mdev c library: glibc, eglibc, dietlibc er no, it doesn't. Yours Martin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120810084843.gg10...@anguilla.debian.or.at
Re: Bug#684396: ITP: openrc -- alternative boot mechanism that manages the services, startup and shutdown of a host
On Aug 10, Philip Hands p...@hands.com wrote: Now that they've done the bulk of the effort, do you really expect them to simply discard their work because you tell them to? I really do not care about what the openrc developers will do, my interest is in what Debian developers will do. So, please tell us about the corrosive harm that you think is going to result from this being allowed into the archive (in detail, with references), or let them get on with it. There are two main issues with trying to support multiple init systems. The first one is the time needed to do it. The second and more important one is being limited by the features of the less capable implementation, which would be a disgrace. -- ciao, Marco signature.asc Description: Digital signature
Re: Bug#684396: ITP: openrc -- alternative boot mechanism that manages the services, startup and shutdown of a host
On Aug 10, Martin Wuertele m...@debian.org wrote: http://www.redhat.com/archives/rhl-devel-list/2008-January/msg00861.html And that really explains why there is a choice for core functions like kernel event handler: udevd, hotplug2, mdev c library: glibc, eglibc, dietlibc They exist, and guess what? We do not allow Debian users to choose among them. Good point. -- ciao, Marco signature.asc Description: Digital signature
Re: Bug#684396: ITP: openrc -- alternative boot mechanism that manages the services, startup and shutdown of a host
* Marco d'Itri m...@linux.it [2012-08-10 11:27]: On Aug 10, Martin Wuertele m...@debian.org wrote: http://www.redhat.com/archives/rhl-devel-list/2008-January/msg00861.html And that really explains why there is a choice for core functions like kernel event handler: udevd, hotplug2, mdev c library: glibc, eglibc, dietlibc They exist, and guess what? We do not allow Debian users to choose among them. Good point. We do not have them in the archive does not mean we did not allow users to chose if we had them. That we do no longer have glibc in the archive and we had a transition to eglibc was an understandable maintainer decision. How is core funcionality defined anyways? If network is considered a core function and then we have net-tools and iprout, ifupdown, network-manager, wicd, ethtool, mii-diag, and users do have a choice. We do not yet have mdev in the archive but I hope that changes with the next release. Yours Martin. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120810095617.gi10...@anguilla.debian.or.at
Re: Bug#684396: ITP: openrc -- alternative boot mechanism that manages the services, startup and shutdown of a host
Le vendredi 10 août 2012 à 11:56 +0200, Martin Wuertele a écrit : That we do no longer have glibc in the archive and we had a transition to eglibc was an understandable maintainer decision. glibc/eglibc is not comparable to the other alternatives, the differences are extremely tiny. How is core funcionality defined anyways? If network is considered a core function and then we have net-tools and iprout, ifupdown, network-manager, wicd, ethtool, mii-diag, and users do have a choice. And this leads to poor user experience because none of these alternatives offers everything we expect from the networking system. We do not yet have mdev in the archive but I hope that changes with the next release. I can’t wait to see the brokenness it will bring. -- .''`. Josselin Mouette : :' : `. `' `- -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1344597000.4958.13.camel@tomoyo
Re: Bug#684396: ITP: openrc -- alternative boot mechanism that manages the services, startup and shutdown of a host
On Fri, Aug 10, 2012 at 09:03:19AM +0800, Chow Loong Jin wrote: On 10/08/2012 08:04, Steve Langasek wrote: On Fri, Aug 10, 2012 at 01:16:17AM +0200, Adam Borowski wrote: Wasn't the idea of porting to non-Linux rejected by upstart's upstream? Porting upstart to non-Linux kernels has never been rejected by upstream. It just requires porters to do the porting; no one involved in upstart upstream has any applicable BSD or Hurd porting experience. If I recall correctly, non-Linux ports were required by upstream to be maintained in a separate bzr branch, because upstart's upstream did not want compatibility code inside the main code-base. This sounds very much like if you want to port it, fork it. That was several years ago, and there's a new upstream maintainer of upstart now. This would be open to rediscussion if there were any interested porters to discuss it with. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Re: Bug#684396: ITP: openrc -- alternative boot mechanism that manages the services, startup and shutdown of a host
On Fri, Aug 10, 2012 at 10:55:51AM +0200, Marco d'Itri wrote: There are two main issues with trying to support multiple init systems. The first one is the time needed to do it. The second and more important one is being limited by the features of the less capable implementation, which would be a disgrace. I tried to change from sysvinit to systemd for checking the improvements it brings and had to move back because of http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=618862 so I guess less capable implementation is in this case a very relative term and mostly depends on the used features of the user... btw one of the most wanted features of at least systemd is discussed here: http://lists.fedoraproject.org/pipermail/devel/2012-June/169365.html -- ciao, Marco Kind regards Harald Jenny -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120810192020.ga3...@harald-has.a-little-linux-box.at
Re: Bug#684396: ITP: openrc -- alternative boot mechanism that manages the services, startup and shutdown of a host
On Fri, 2012-08-10 at 00:50 +0200, Josselin Mouette wrote: Le jeudi 09 août 2012 à 23:53 +0200, Carlos Alberto Lopez Perez a écrit : What about Debian kFreeBSD and Hurd? AFAIK systemd needs a linux kernel to work. Please explain again why we should cripple the Linux port for the sake of toy ports? Please calm down, Debian is bigger in scope than GNU/Linux only, fortunately! And the openrc packaging initiative is a _very_ good proposal! -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1344635248.25305.6.camel@x60
Bug#684396: ITP: openrc -- alternative boot mechanism that manages the services, startup and shutdown of a host
Package: wnpp Severity: wishlist Owner: XU Benda hero...@gentoo.org * Package name: openrc Version : 0.10.5 Upstream Author : Gentoo OpenRC Team ope...@gentoo.org * URL : http://www.gentoo.org/proj/en/base/openrc/ * License : 2 clause BSD Programming Lang: C, shell script Description : alternative boot mechanism that manages the services, startup and shutdown of a host OpenRC is a dependency based init system that works with the system provided init program, normally /sbin/init. It is not a replacement for /sbin/init, but an alternative to /etc/init.d/rc from sysv-rc. OpenRC understands LSB headers, providing a smooth way to switch back and forth with sysv-rc. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120809130307.7498.64495.reportbug@localhost
Re: Bug#684396: ITP: openrc -- alternative boot mechanism that manages the services, startup and shutdown of a host
Please do not bother. openrc was recently discussed on debian-devel@ and there was a large consensus that it is not a credible alternative to upstart and systemd. We do not need to be able to choose among multiple init implementations. -- ciao, Marco signature.asc Description: Digital signature
Re: Bug#684396: ITP: openrc -- alternative boot mechanism that manages the services, startup and shutdown of a host
On 2012-08-09 15:54:05 +0200 (+0200), Marco d'Itri wrote:
Please do not bother.
[...]
Last I recall from that thread, Roger Leigh was coordinating with
Gentoo upstream to incorporate/wrap the necessary functionality to
parse LSB header comments already present in Debian's init scripts.
He also seems to be involved in this ITP as the submitter's mentor,
judging from:
http://wiki.debian.org/OpenRC
So I would assume this ITP is merely an outcome of that debian-devel
discussion, based on work which has been taking place behind the
scenes since the thread died down.
--
{ IRL(Jeremy_Stanley); WWW(http://fungi.yuggoth.org/); PGP(43495829);
WHOIS(STANL3-ARIN); SMTP(fu...@yuggoth.org); FINGER(fu...@yuggoth.org);
MUD(kin...@katarsis.mudpy.org:6669); IRC(fu...@irc.yuggoth.org#ccl); }
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120809150317.gl3...@yuggoth.org
Re: Bug#684396: ITP: openrc -- alternative boot mechanism that manages the services, startup and shutdown of a host
On Aug 09, The Fungi fu...@yuggoth.org wrote: So I would assume this ITP is merely an outcome of that debian-devel discussion, I think that the outcome of that discussion was that openrc would be too little too late for Debian, and that it is proven that trying to support well multiple init implementations does not work. -- ciao, Marco signature.asc Description: Digital signature
Re: Bug#684396: ITP: openrc -- alternative boot mechanism that manages the services, startup and shutdown of a host
* Marco d'Itri m...@linux.it [2012-08-09 16:12]: Please do not bother. openrc was recently discussed on debian-devel@ and there was a large consensus that it is not a credible alternative to upstart and systemd. It was a very long discussion that did not end in a major consensus the way I read it. Consensus was only between those favoring an event driven system but the advantages or requirements for an event driven system have not yet fully been disclosed in such a way that all questions raised are answered. We do not need to be able to choose among multiple init implementations. According to my latest information only the DPL may speak on behalf of the project which can by overridden by way of a GR. I therefore conclude that YOU don't want to be able to chose among multiple init implementatioins. Yours Martin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120809164229.gb10...@anguilla.debian.or.at
Re: Bug#684396: ITP: openrc -- alternative boot mechanism that manages the services, startup and shutdown of a host
On Thu, Aug 09, 2012 at 03:54:05PM +0200, Marco d'Itri wrote: Please do not bother. openrc was recently discussed on debian-devel@ and there was a large consensus that it is not a credible alternative to upstart and systemd. openrc is not acceptable from the very start, as it lacks a key part: a hostile upstream. That seems to be the main requirement for Debian. (Not going into actual technical reasons, I took part in too many flamewars recently already.) -- Copyright and patents were never about promoting culture and innovations; from the very start they were legalized bribes to give the king some income and to let businesses get rid of competition. For some history, please read https://en.wikipedia.org/wiki/Statute_of_Monopolies_1623 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120809204044.ga16...@angband.pl
Re: Bug#684396: ITP: openrc -- alternative boot mechanism that manages the services, startup and shutdown of a host
Le jeudi 09 août 2012 à 18:42 +0200, Martin Wuertele a écrit : We do not need to be able to choose among multiple init implementations. According to my latest information only the DPL may speak on behalf of the project which can by overridden by way of a GR. I therefore conclude that YOU don't want to be able to chose among multiple init implementatioins. It’s not a question of wanting it or not. It is a stupid thing to do, which brings us more work with no added value for our users. And no, choice between multiple broken implementation is NOT added value. Linux is not about choice. -- .''`. Josselin Mouette : :' : `. `' `- -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1344545887.4958.6.camel@tomoyo
Re: Bug#684396: ITP: openrc -- alternative boot mechanism that manages the services, startup and shutdown of a host
On 09/08/12 15:54, Marco d'Itri wrote: Please do not bother. openrc was recently discussed on debian-devel@ and there was a large consensus that it is not a credible alternative to upstart and systemd. We do not need to be able to choose among multiple init implementations. What about Debian kFreeBSD and Hurd? AFAIK systemd needs a linux kernel to work. signature.asc Description: OpenPGP digital signature
Re: Bug#684396: ITP: openrc -- alternative boot mechanism that manages the services, startup and shutdown of a host
On Thu, Aug 09, 2012 at 10:40:44PM +0200, Adam Borowski wrote: On Thu, Aug 09, 2012 at 03:54:05PM +0200, Marco d'Itri wrote: Please do not bother. openrc was recently discussed on debian-devel@ and there was a large consensus that it is not a credible alternative to upstart and systemd. openrc is not acceptable from the very start, as it lacks a key part: a hostile upstream. That seems to be the main requirement for Debian. Ah, that must be why the community hasn't rallied around upstart yet... we aren't being hostile enough! Thanks for helping me understand, I'll do what I can to make sure Canonical is being appropriately hostile wrt upstart from now on. ;) -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Re: Bug#684396: ITP: openrc -- alternative boot mechanism that manages the services, startup and shutdown of a host
Le jeudi 09 août 2012 à 23:53 +0200, Carlos Alberto Lopez Perez a écrit : What about Debian kFreeBSD and Hurd? AFAIK systemd needs a linux kernel to work. Please explain again why we should cripple the Linux port for the sake of toy ports? -- .''`. Josselin Mouette : :' : `. `' `- -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1344552643.4958.7.camel@tomoyo
Re: Bug#684396: ITP: openrc -- alternative boot mechanism that manages the services, startup and shutdown of a host
On Thu, Aug 09, 2012 at 05:37:57PM +0200, Marco d'Itri wrote: On Aug 09, The Fungi fu...@yuggoth.org wrote: So I would assume this ITP is merely an outcome of that debian-devel discussion, I think that the outcome of that discussion was that openrc would be too little too late for Debian, and that it is proven that trying to support well multiple init implementations does not work. In the case of OpenRC, it has the potential to be a drop-in replacement for sysv-rc (note that it uses base sysvinit still underneath that). With the work that Benda Xu has done to make OpenRC work with LSB init scripts, it can now run standard Debian init scripts. There's work going on in openrc upstream to allow introspection of OpenRC dependencies dynamically (it's possible now, but without a standard interface). This will potentially let insserv and other tools (systemd etc.) add support for integrating OpenRC dependencies into their normal operation. The first allows a migration path to using OpenRC; the latter allows a migration path from LSB to OpenRC scripts. Working on getting OpenRC to work on Debian is not without value. For me, the entire point of the exercise is to explore the feasability to port it and evaluate it as an alternative/replacement for sysv-rc; this is almost completely orthogonal to work on systemd/upstart, which will for the most part be unaffected by this. Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linuxhttp://people.debian.org/~rleigh/ `. `' schroot and sbuild http://alioth.debian.org/projects/buildd-tools `-GPG Public Key F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120809230132.gb25...@codelibre.net
Re: Bug#684396: ITP: openrc -- alternative boot mechanism that manages the services, startup and shutdown of a host
On Thu, Aug 09, 2012 at 02:51:49PM -0700, Steve Langasek wrote: On Thu, Aug 09, 2012 at 10:40:44PM +0200, Adam Borowski wrote: On Thu, Aug 09, 2012 at 03:54:05PM +0200, Marco d'Itri wrote: Please do not bother. openrc was recently discussed on debian-devel@ and there was a large consensus that it is not a credible alternative to upstart and systemd. openrc is not acceptable from the very start, as it lacks a key part: a hostile upstream. That seems to be the main requirement for Debian. Ah, that must be why the community hasn't rallied around upstart yet... we aren't being hostile enough! Thanks for helping me understand, I'll do what I can to make sure Canonical is being appropriately hostile wrt upstart from now on. ;) Wasn't the idea of porting to non-Linux rejected by upstart's upstream? With nowhere as much hostility as systemd's, though -- if I recall correctly, it was something like do all the work yourself, we won't help you even with merging patches, as opposed to systemd no because no, over my dead body. With people like you around, this is something that's solvable. -- Copyright and patents were never about promoting culture and innovations; from the very start they were legalized bribes to give the king some income and to let businesses get rid of competition. For some history, please read https://en.wikipedia.org/wiki/Statute_of_Monopolies_1623 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120809231617.ga25...@angband.pl
Re: Bug#684396: ITP: openrc -- alternative boot mechanism that manages the services, startup and shutdown of a host
On Fri, Aug 10, 2012 at 12:50:43AM +0200, Josselin Mouette wrote: Le jeudi 09 août 2012 à 23:53 +0200, Carlos Alberto Lopez Perez a écrit : What about Debian kFreeBSD and Hurd? AFAIK systemd needs a linux kernel to work. Please explain again why we should cripple the Linux port for the sake of toy ports? I'm not sure that this is true. OpenRC can (on Linux) use cgroups and hence do some of the more advanced stuff that systemd does. Yet it still runs on other platforms. This is in part due to the fact that OpenRC is written to be portable, while the systemd developers have an asoundingly bad attitude with respect to this. It would be perfectly possible for systemd to support other platforms if they really wanted to; it probably wouldn't even be that hard. Roger -- .''`. Roger Leigh : :' : Debian GNU/Linuxhttp://people.debian.org/~rleigh/ `. `' schroot and sbuild http://alioth.debian.org/projects/buildd-tools `-GPG Public Key F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120809231631.gc25...@codelibre.net
Re: Bug#684396: ITP: openrc -- alternative boot mechanism that manages the services, startup and shutdown of a host
Hi! systemd's upstream is not hostile at all - systemd just relies on many Linux-specific technologies, not just cgroups, and therefore it is not easily possible to port it. Upstream suggested to fork systemd and maintain patches for other OSes there, because they don't want a construct with lots of #ifdefs which is hard to debug and doesn't work as expected on all platforms. (supporting multiple platforms is a huge effort) So far nobody has created a non-Linux fork of systemd, and the reason is mainly that it is too much work. Cheers, Matthias 2012/8/10 Roger Leigh rle...@codelibre.net: On Fri, Aug 10, 2012 at 12:50:43AM +0200, Josselin Mouette wrote: Le jeudi 09 août 2012 à 23:53 +0200, Carlos Alberto Lopez Perez a écrit : What about Debian kFreeBSD and Hurd? AFAIK systemd needs a linux kernel to work. Please explain again why we should cripple the Linux port for the sake of toy ports? I'm not sure that this is true. OpenRC can (on Linux) use cgroups and hence do some of the more advanced stuff that systemd does. Yet it still runs on other platforms. This is in part due to the fact that OpenRC is written to be portable, while the systemd developers have an asoundingly bad attitude with respect to this. It would be perfectly possible for systemd to support other platforms if they really wanted to; it probably wouldn't even be that hard. Roger -- .''`. Roger Leigh : :' : Debian GNU/Linuxhttp://people.debian.org/~rleigh/ `. `' schroot and sbuild http://alioth.debian.org/projects/buildd-tools `-GPG Public Key F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120809231631.gc25...@codelibre.net -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/caknhny-a_7vqnxva+mzcmz3vofvdn4iczthf2bpyhesrvna...@mail.gmail.com
Re: Bug#684396: ITP: openrc -- alternative boot mechanism that manages the services, startup and shutdown of a host
On Fri, Aug 10, 2012 at 01:16:17AM +0200, Adam Borowski wrote: Wasn't the idea of porting to non-Linux rejected by upstart's upstream? Porting upstart to non-Linux kernels has never been rejected by upstream. It just requires porters to do the porting; no one involved in upstart upstream has any applicable BSD or Hurd porting experience. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Re: Bug#684396: ITP: openrc -- alternative boot mechanism that manages the services, startup and shutdown of a host
On 10/08/2012 08:04, Steve Langasek wrote: On Fri, Aug 10, 2012 at 01:16:17AM +0200, Adam Borowski wrote: Wasn't the idea of porting to non-Linux rejected by upstart's upstream? Porting upstart to non-Linux kernels has never been rejected by upstream. It just requires porters to do the porting; no one involved in upstart upstream has any applicable BSD or Hurd porting experience. If I recall correctly, non-Linux ports were required by upstream to be maintained in a separate bzr branch, because upstart's upstream did not want compatibility code inside the main code-base. This sounds very much like if you want to port it, fork it. -- Kind regards, Loong Jin signature.asc Description: OpenPGP digital signature
Re: Bug#684396: ITP: openrc -- alternative boot mechanism that manages the services, startup and shutdown of a host
On Aug 10, Roger Leigh rle...@codelibre.net wrote: In the case of OpenRC, it has the potential to be a drop-in replacement for sysv-rc (note that it uses base sysvinit still underneath that). So do the other init systems. The point is what they can do which sysvinit (and openrc) cannot. -- ciao, Marco signature.asc Description: Digital signature
Re: Bug#684396: ITP: openrc -- alternative boot mechanism that manages the services, startup and shutdown of a host
On 08/09/2012 09:54 PM, Marco d'Itri wrote: openrc was recently discussed on debian-devel@ and there was a large consensus that it is not a credible alternative to upstart and systemd. That's clearly *not* truth. Thomas -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/5024904a.5080...@debian.org
