Re: [gentoo-dev] Making systemd more accessible to normal users
On Wed, May 15, 2013 at 03:41:31PM +0200, Fabio Erculiani wrote: And now that GNOME 3.8 is out, the game starts over again: logind is a hard requirement, logind is part of systemd, starting logind (which replaces consolekit) is not that trivial as you may think (and is the thing I started to work on anyway). I'm not aware of GNOME 3.8 having a hard requirement on logind. Could you please show where that is? -- Regards, Olav
Re: [gentoo-dev] Making systemd more accessible to normal users
Olav Vitters schrieb: And now that GNOME 3.8 is out, the game starts over again: logind is a hard requirement, logind is part of systemd, starting logind (which replaces consolekit) is not that trivial as you may think (and is the thing I started to work on anyway). I'm not aware of GNOME 3.8 having a hard requirement on logind. Could you please show where that is? The bug report about this issue states to which extent GNOME 3.8 needs logind, and contains pointers to the relevant commits. https://bugs.gentoo.org/show_bug.cgi?id=464944 Best regards, Chí-Thanh Christopher Nguyễn
Re: [gentoo-dev] Making systemd more accessible to normal users
On Fri, Jun 07, 2013 at 02:04:38PM +0200, Chí-Thanh Christopher Nguyễn wrote: Olav Vitters schrieb: And now that GNOME 3.8 is out, the game starts over again: logind is a hard requirement, logind is part of systemd, starting logind (which replaces consolekit) is not that trivial as you may think (and is the thing I started to work on anyway). I'm not aware of GNOME 3.8 having a hard requirement on logind. Could you please show where that is? The bug report about this issue states to which extent GNOME 3.8 needs logind, and contains pointers to the relevant commits. https://bugs.gentoo.org/show_bug.cgi?id=464944 That bugreport is regarding an optional dependency for the power handling. It is correct that Ubuntu will switch from ConsoleKit to logind, so it does make sense to either maintain ConsoleKit or use logind. But it still is an optional dependency. I do agree with https://bugs.gentoo.org/show_bug.cgi?id=464944#c11 (probably easier for all to just use it, it does not require systemd to be the init). -- Regards, Olav
Re: [gentoo-dev] Making systemd more accessible to normal users
Olav Vitters schrieb: https://bugs.gentoo.org/show_bug.cgi?id=464944 That bugreport is regarding an optional dependency for the power handling. It is correct that Ubuntu will switch from ConsoleKit to logind, so it does make sense to either maintain ConsoleKit or use logind. But it still is an optional dependency. You are correct that it is not a hard dependency in a strict sense. However, suspend support and session management are not obscure seldom-used functions. So logind becomes a hard requirement for enough users which justifies calling it that way. Best regards, Chí-Thanh Christopher Nguyễn
Re: [gentoo-dev] Making systemd more accessible to normal users
On Fri, Jun 07, 2013 at 02:34:27PM +0200, Chí-Thanh Christopher Nguyễn wrote: Olav Vitters schrieb: https://bugs.gentoo.org/show_bug.cgi?id=464944 That bugreport is regarding an optional dependency for the power handling. It is correct that Ubuntu will switch from ConsoleKit to logind, so it does make sense to either maintain ConsoleKit or use logind. But it still is an optional dependency. You are correct that it is not a hard dependency in a strict sense. However, suspend support and session management are not obscure seldom-used functions. So logind becomes a hard requirement for enough users which justifies calling it that way. You can still use ConsoleKit, why are you saying session management? The suspend I'm not sure about. Regarding hard requirment: You do *not* need systemd to compile GNOME. You do *not* need logind. We do make use of various APIs and you're encouraged/recommended to use a few things (either API or e.g. logind). If it is phrased as hard requirement this continues the messages on this gentoo-dev where it is suggested that things are forced. In practice we do not have a hard requirement. AFAIK nobody stepped up to maintain ConsoleKit. Ubuntu would, but they went with logind. I'd encourage people to actually maintain ConsoleKit. Saying we use something that's maintained and solved some design issues in ConsoleKit is a bit easy. -- Regards, Olav
Re: [gentoo-dev] Making systemd more accessible to normal users
El mié, 15-05-2013 a las 20:28 -0500, Matthew Thode escribió: On 05/15/13 19:27, William Hubbs wrote: On Wed, May 15, 2013 at 10:16:01PM +0800, Ben de Groot wrote: We don't control upstreams, but we still have choices. At this point I only see Gnome and udev upstreams who are forcing their users to use systemd. (There may be other projects too that I'm not aware of.) Udev doesn't force anything. In fact upstream makes it clear that udev can be run without systemd. William so then we should decouple logind from udev downstream (packaging) :D That is being handled in: https://bugs.gentoo.org/show_bug.cgi?id=461940 but help is needed on that :|
Re: [gentoo-dev] Making systemd more accessible to normal users
On Wed, May 15, 2013 at 04:08:17PM +0200, Pacho Ramos wrote: El mié, 15-05-2013 a las 15:41 +0200, Fabio Erculiani escribió: Are we realizing that in order to keep systemd out of our way, we're currently writing and maintaining drop-in replacements for the features that systemd is already providing in an actively maintained state? openrc-settingsd was the first thing that we as Gentoo developers (Pacho?) had to write in order to merge GNOME 3.6 into our tree. Tetromino is the expert in openrc-settingsd I think, I don't know much about it :S I don't either, but I do think this is why it was written -- to allow using gnome 3.6 without systemd. But, well, I think the easiest solution would be to move to systemd and run the parts we need from it even still booting with openrc I would be willing to consider this option. Having systemd installed doesn't mean that you are running it, and there are parts of the systemd package (like udev) that do not require systemd to be running. I don't know if there are any down sides to this arrangement other than the extra disk space the systemd components would use. This idea is probably a topic for another thread though. William signature.asc Description: Digital signature
Re: [gentoo-dev] Making systemd more accessible to normal users
I'll start answering from the last point since it explains the remaining answers. Sorry for the shuffle. On Tue, 14 May 2013 10:41:27 +0200 Luca Barbato lu_z...@gentoo.org wrote: On 05/10/2013 09:45 AM, Ralph Sennhauser wrote: [1] http://fedoraproject.org/wiki/Packaging:Systemd#Unit_Files In the end initscripts are usually distribution dependent since they are an integration step. Integration? What kind of integration? The kind of integration which results in various apps behaving differently depending on the patch set used by distro? The kind of integration which makes performing *simple* administrative tasks completely distro-dependant? Seriously, I don't remember anymore how to enable services on openrc. And I don't want to get back to the point when approach a computer with Arch required me to find out how the necessary tools are named there. That said, Gentoo init.d scripts are an aberration. Either they resemble poor hacks to change application behavior, provide additional configuration or setup. Isn't init script supposed to *start* an application? When init scripts start to source additional code from external files, poorly parse configuration files and reset databases, I believe we reached the point of 'done seriously wrong'. And someone mentioned that automatic restart of service is dangerous... What if openrc/upstart/runit devs start harassing upstream in the same way? Strategically is great, but isn't exactly something nice to do. Probably people caring about alternatives should start bothering upstreams likewise and we'll see how it goes. Strategically? So we're now at war? Yes, I've noticed the few people fancying a pile of hacks complaining about the 'so-wrong' systemd breaking the unwritten rules of having a distro-specific pile of hacks and trying to improve something for the sake of uniformity. The point is that openrc/upstart/runit devs never cared enough. Maybe they fancied their total control over init scripts or didn't feel influential enough, I don't know. Now that we have something that actually was designed with that point in consideration, we have crybabies shouting 'but please use my init.d instead! it's so much better because i used it'. The major difference would be that systemd is something new, not just the pile of hacks that has grown a lot of functionality over time. I'm sure that *everybody* would be delighted to provide those 4-5 different initscripts because one distribution or the other wants others do the work for them... Does it really? I more feel like it specifically doesn't want others to touch their precious init scripts. I'm saying again that trying to get a good intermediate representation and have a generator (eselect based maybe) provide the init-specific file would be much better. Did you see how systemd unit files look like? What kind of intermediate representation do you want? I don't expect service descriptions to go much simpler than this. Of course, you could just mangle the names, change the format. Do that for the sake of making things harder for others. Show how offended you are by others not wanting your fancy init.d! And eselect, of course. Another distro-specific pile of hacks which doesn't do anything specific. I wonder if we will have to wait for Fedora to replace it. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] Making systemd more accessible to normal users
Are we realizing that in order to keep systemd out of our way, we're currently writing and maintaining drop-in replacements for the features that systemd is already providing in an actively maintained state? openrc-settingsd was the first thing that we as Gentoo developers (Pacho?) had to write in order to merge GNOME 3.6 into our tree. And now that GNOME 3.8 is out, the game starts over again: logind is a hard requirement, logind is part of systemd, starting logind (which replaces consolekit) is not that trivial as you may think (and is the thing I started to work on anyway). And if this wasn't enough, it means that if you want GNOME 3.8, you need to get logind, which may or not may get included in our udev ebuild and if it won't, it means that you will be forced to use systemd as device manager if you want GNOME 3.8, which is believe it or not, the thing that Ubuntu did. The problem will only increase in size as the clock moves. And (and!) how does all this fit together with eudev? If the idea is to either put logind in udev (thus, not creating a separate logind ebuild), it means that eudev is already a dead end for GNOME users, unless the eudev team is going to provide logind as well. I don't want to start a flamewar here, I was the one who called Lennart software lennartware, but science is science, and a reality check had to be done: at some near point in the future, our users will be forced to replace udev/eudev with systemd. Like it. Or not. While I successfully use both openrc and systemd, I _do_ think that (and expect to see) more and more users (and developers) will be switching to systemd. Is there anything we can do? Besides being prepared, I don't think so. Do we control upstreams? No, sorry. So what do we want to do then? Isolate from the rest of the world? (It's not a sarcastic question). I hope that everybody does their own reality check. -- Fabio Erculiani
Re: [gentoo-dev] Making systemd more accessible to normal users
On Wed, May 15, 2013 at 9:41 AM, Fabio Erculiani lx...@gentoo.org wrote: And (and!) how does all this fit together with eudev? If the idea is to either put logind in udev (thus, not creating a separate logind ebuild), it means that eudev is already a dead end for GNOME users, unless the eudev team is going to provide logind as well. I picked this paragraph to quote, but this is more of an overall response to your email. Gentoo is about choice, but that doesn't mean that every developer has to support every possible choice on every package. Eudev not working with gnome is not a reason to hold back either project. Not every option in Gentoo has to be compatible with every other option. Eudev is welcome to stay even if its developers are its only users. I do agree in general that systemd seems pretty likely to take over, but that doesn't mean that those who aren't running big desktop environments can't make use of the alternatives, or that providing alternatives is bad. I doubt you'll ever get Gnome 3.8 running on Prefix either. :) Rich
Re: [gentoo-dev] Making systemd more accessible to normal users
El mié, 15-05-2013 a las 15:41 +0200, Fabio Erculiani escribió: Are we realizing that in order to keep systemd out of our way, we're currently writing and maintaining drop-in replacements for the features that systemd is already providing in an actively maintained state? openrc-settingsd was the first thing that we as Gentoo developers (Pacho?) had to write in order to merge GNOME 3.6 into our tree. Tetromino is the expert in openrc-settingsd I think, I don't know much about it :S And now that GNOME 3.8 is out, the game starts over again: logind is a hard requirement, logind is part of systemd, starting logind (which replaces consolekit) is not that trivial as you may think (and is the thing I started to work on anyway). And if this wasn't enough, it means that if you want GNOME 3.8, you need to get logind, which may or not may get included in our udev ebuild and if it won't, it means that you will be forced to use systemd as device manager if you want GNOME 3.8, which is believe it or not, the thing that Ubuntu did. Ubuntu is installing systemd to get their udev and logind... but still using upstart (with gnome 3.8 packages) But, well, I think the easiest solution would be to move to systemd and run the parts we need from it even still booting with openrc
Re: [gentoo-dev] Making systemd more accessible to normal users
On 15 May 2013 21:41, Fabio Erculiani lx...@gentoo.org wrote: Are we realizing that in order to keep systemd out of our way, we're currently writing and maintaining drop-in replacements for the features that systemd is already providing in an actively maintained state? openrc-settingsd was the first thing that we as Gentoo developers (Pacho?) had to write in order to merge GNOME 3.6 into our tree. It's well known that Gnome is part and parcel of the whole vertical integration circus. And (and!) how does all this fit together with eudev? If the idea is to either put logind in udev (thus, not creating a separate logind ebuild), it means that eudev is already a dead end for GNOME users, unless the eudev team is going to provide logind as well. I'm not sure what the eudev team is planning, but it's been working well so far for me. And since I don't use Gnome, it's not an issue as long as other desktop environments are not making the same mistakes. I don't want to start a flamewar here, I was the one who called Lennart software lennartware, but science is science, and a reality check had to be done: at some near point in the future, our users will be forced to replace udev/eudev with systemd. Like it. Or not. This isn't science. And unless you use Gnome, I don't see why we would be forced to use systemd. KDE, Xfce, LXDE and Razor-qt are still happy to support non-systemd operating systems. The way I see it is that Gnome is making itself more of a non-option on Gentoo, Slackware and BSD systems. While I successfully use both openrc and systemd, I _do_ think that (and expect to see) more and more users (and developers) will be switching to systemd. Is there anything we can do? Besides being prepared, I don't think so. Do we control upstreams? No, sorry. We don't control upstreams, but we still have choices. At this point I only see Gnome and udev upstreams who are forcing their users to use systemd. (There may be other projects too that I'm not aware of.) So what do we want to do then? Isolate from the rest of the world? (It's not a sarcastic question). I hope that everybody does their own reality check. We say that Gentoo stands for choice. That is why we should resist allowing systemd (and Gnome) to take those choices away with their mistaken idea of vertical integration. We do have other options. -- Cheers, Ben | yngwin Gentoo developer
Re: [gentoo-dev] Making systemd more accessible to normal users
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 15/05/13 10:16 AM, Ben de Groot wrote: On 15 May 2013 21:41, Fabio Erculiani lx...@gentoo.org wrote: And (and!) how does all this fit together with eudev? If the idea is to either put logind in udev (thus, not creating a separate logind ebuild), it means that eudev is already a dead end for GNOME users, unless the eudev team is going to provide logind as well. I'm not sure what the eudev team is planning, but it's been working well so far for me. And since I don't use Gnome, it's not an issue as long as other desktop environments are not making the same mistakes. We don't know what we're planning either -- this is the first that I heard sys-fs/udev maintainers are considering bundling logind. Gut reaction is that eudev isn't going to do this, but the eudev team of course need to have an actual discussion and decision on it as a project. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) iF4EAREIAAYFAlGTovIACgkQ2ugaI38ACPDVZQD/dJUbQ9oMl9BAiMuM+SwtETad PkhRLDVaBEN2FqwXFQIA/3wPouBLnzHT1p1uNL5zfcc8Hf/RgFoKKbaZ/deZM6s2 =xukU -END PGP SIGNATURE-
Re: [gentoo-dev] Making systemd more accessible to normal users
On 05/15/2013 03:41 PM, Fabio Erculiani wrote: Are we realizing that in order to keep systemd out of our way, we're currently writing and maintaining drop-in replacements for the features that systemd is already providing in an actively maintained state? openrc-settingsd was the first thing that we as Gentoo developers (Pacho?) had to write in order to merge GNOME 3.6 into our tree. And now that GNOME 3.8 is out, the game starts over again: logind is a hard requirement, logind is part of systemd, starting logind (which replaces consolekit) is not that trivial as you may think (and is the thing I started to work on anyway). And if this wasn't enough, it means that if you want GNOME 3.8, you need to get logind, which may or not may get included in our udev ebuild and if it won't, it means that you will be forced to use systemd as device manager if you want GNOME 3.8, which is believe it or not, the thing that Ubuntu did. The problem will only increase in size as the clock moves. And given that the end-plan according to the guys is to kill the distributions shall we just close Gentoo now? And (and!) how does all this fit together with eudev? If the idea is to either put logind in udev (thus, not creating a separate logind ebuild), it means that eudev is already a dead end for GNOME users, unless the eudev team is going to provide logind as well. Are there specifications regarding logind ? Is that so incredibly terrible write and maintain 1k loc? I don't want to start a flamewar here, I was the one who called Lennart software lennartware, but science is science, and a reality check had to be done: at some near point in the future, our users will be forced to replace udev/eudev with systemd. Like it. Or not. Science is science, systemd doesn't work with anything but linux, Gentoo in theory should care about not-linux. While I successfully use both openrc and systemd, I _do_ think that (and expect to see) more and more users (and developers) will be switching to systemd. Surely sysadmins will be delighted about that. Is there anything we can do? Besides being prepared, I don't think so. Do we control upstreams? No, sorry. I'm upstream for some stuff, vlc was already really close to force-kill pulseaudio because of some cute problems, the thing got otherwise fixed. Upstream does what is most sensible for the users, usually. Freebsd, openbsd and some other operating systems are still there, they have their reasons and usually work better in those fields than other, I'm sure some people would wish to kill them, not going to happen anytime soon. So what do we want to do then? Isolate from the rest of the world? The world is bigger than that and we were making bridges around, *why* severing them because somebody else decided for you? (It's not a sarcastic question). I hope that everybody does their own reality check. Did mine, other experienced the hard way what I said many times. Gnome doesn't seem a good reason to leave in the cold people that do not even care about it. lu
Re: [gentoo-dev] Making systemd more accessible to normal users
On 05/15/2013 05:03 PM, Luca Barbato wrote: On 05/15/2013 03:41 PM, Fabio Erculiani wrote: Are we realizing that in order to keep systemd out of our way, we're currently writing and maintaining drop-in replacements for the features that systemd is already providing in an actively maintained state? openrc-settingsd was the first thing that we as Gentoo developers (Pacho?) had to write in order to merge GNOME 3.6 into our tree. To make it even clearer. In order to support a good amount of users out there that do not care about gnome and cannot use systemd we can see and bake alternatives that are compatible enough. Those that can't use systemd: - those not using the latest glibc (and maybe uclibc) - those not using a recent linux kernel - not sure about cgroups-users, the lxc vs systemd problem should be solved I hope That's what I'm aware of. lu
Re: [gentoo-dev] Making systemd more accessible to normal users
On Wed, 15 May 2013 17:10:03 +0200 Luca Barbato lu_z...@gentoo.org wrote: - those not using the latest glibc (and maybe uclibc) Did you test this? Are there more specific details regarding this? Which version don't work? Is it known why? - those not using a recent linux kernel It works on all gentoo-sources kernels (I test them), is 2.6 meant with not recent or are these kernels even older? Those kind of people likely don't care much about upgrading anyway and thus don't need systemd, but they rather enjoy to have a system full of security issues. -- With kind regards, Tom Wijsman (TomWij) Gentoo Developer E-mail address : tom...@gentoo.org GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D signature.asc Description: PGP signature
Re: [gentoo-dev] Making systemd more accessible to normal users
On Wed, May 15, 2013 at 12:59 PM, Tom Wijsman tom...@gentoo.org wrote: On Wed, 15 May 2013 17:10:03 +0200 Luca Barbato lu_z...@gentoo.org wrote: - those not using the latest glibc (and maybe uclibc) Did you test this? Are there more specific details regarding this? Which version don't work? Is it known why? - those not using a recent linux kernel It works on all gentoo-sources kernels (I test them), is 2.6 meant with not recent or are these kernels even older? Those kind of people likely don't care much about upgrading anyway and thus don't need systemd, but they rather enjoy to have a system full of security issues. Don't take it personally or as an attack on systemd. I think he was just pointing out that there are many use cases where systemd may not be appropriate. I'm sure if you pulled a glibc from 10 years ago there would be a pretty good chance that systemd wouldn't work, but openrc is mainly based on shell (not even bash), so it would be pretty likely to work. Likewise if you picked a kernel from a few years ago systemd with all its use of cgroups and such probably wouldn't work, while openrc is simpler. Certainly if you picked a FreeBSD kernel systemd will not work. (Keep in mind the set of systems not using a recent linux kernel includes all systems that don't run linux at all.) In any case, there really isn't any decision to make here. As long as devs want to support openrc it will be supported. Likewise with eudev. As long as devs want to support systemd and udev those will be options as well. The beauty of Gentoo is that more than any distro it maximizes the options for our users. The changes in Gnome may eliminate Gnome+openrc as a practical option, and when those teams stop supporting the combo then users will have to make a choice to not use one or the other. Gentoo is about choice, but that doesn't mean that we have to offer EVERY possible choice. If somebody wants to support my hp48 calculator as a Gentoo arch that would be great, but that doesn't mean that I can start hassling teams to do the work for me. Gentoo is about working TOGETHER to provide choices, not about telling others to make choices work for you. Rich
Re: [gentoo-dev] Making systemd more accessible to normal users
On Wed, 15 May 2013 17:03:13 +0200 Luca Barbato lu_z...@gentoo.org wrote: On 05/15/2013 03:41 PM, Fabio Erculiani wrote: ... GNOME ... And given that the end-plan according to the guys is to kill the distributions shall we just close Gentoo now? Let's not exaggerate things, there are a ton of other DEs out there; are all of them starting to depend on systemd specific features? And (and!) how does all this fit together with eudev? If the idea is to either put logind in udev (thus, not creating a separate logind ebuild), it means that eudev is already a dead end for GNOME users, unless the eudev team is going to provide logind as well. Is that so incredibly terrible write and maintain 1k loc? Whether or not it is terrible, it is a time sink; is it worth doing it? I don't want to start a flamewar here, I was the one who called Lennart software lennartware, but science is science, and a reality check had to be done: at some near point in the future, our users will be forced to replace udev/eudev with systemd. Like it. Or not. Science is science, systemd doesn't work with anything but linux, Gentoo in theory should care about not-linux. Indeed, the goal here is solely to make systemd more accessible; we shouldn't pursue it to be the main init system or force it upon users, unless there are indicators in the future that it became better (eg. supports BSD, ...) for everyone. Whether upstreams will force users remains to be a question to me, this thread indicates a view from the GNOME users side; but that does not target the wide audience that uses other DEs. Is there anything we can do? Besides being prepared, I don't think so. Do we control upstreams? No, sorry. I'm upstream for some stuff, vlc was already really close to force-kill pulseaudio because of some cute problems, the thing got otherwise fixed. Patches are still an option, and if patches become to tedious there is the possibility to fork in the worst caste; if there aren't either of those, we probably don't care enough to provide that piece of software to our users. There's a moment one has to stop caring about certain broken / incompatible pieces of software and throw them out. Freebsd, openbsd and some other operating systems are still there, they have their reasons and usually work better in those fields than other, I'm sure some people would wish to kill them, not going to happen anytime soon. It's better to be neutral than to pursue something you can't accomplish. So what do we want to do then? Isolate from the rest of the world? The world is bigger than that and we were making bridges around, *why* severing them because somebody else decided for you? Indeed, I'd rather embrace than isolate; if something is useful for a large share of users, isolating us from it won't make anybody happy. (It's not a sarcastic question). I hope that everybody does their own reality check. Did mine, other experienced the hard way what I said many times. Gnome doesn't seem a good reason to leave in the cold people that do not even care about it. Used GNOME for months, then with 3.6 - 3.8 it started to break on me; it didn't work on either OpenRC or systemd. While I was a happy user at first, recent events made me lose interest in it; I think a discussion regarding init systems and similar software shouldn't be focused on a single DE, so I too am not sure why focus is laid on GNOME here... -- With kind regards, Tom Wijsman (TomWij) Gentoo Developer E-mail address : tom...@gentoo.org GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D signature.asc Description: PGP signature
Re: [gentoo-dev] Making systemd more accessible to normal users
On Wed, 15 May 2013 13:25:11 -0400 Rich Freeman ri...@gentoo.org wrote: On Wed, May 15, 2013 at 12:59 PM, Tom Wijsman tom...@gentoo.org wrote: Don't take it personally or as an attack on systemd. I think he was just pointing out that there are many use cases where systemd may not be appropriate. In discussions, I try to not root for object X or Y but be constructive. I'm sure if you pulled a glibc from 10 years ago there would be a pretty good chance that systemd wouldn't work, but openrc is mainly based on shell (not even bash), so it would be pretty likely to work. That is, if OpenRC is POSIX.1-2001 compatible; it doesn't use any APIs or programs developed in the last 10 years, it doesn't depend on a certain way a certain feature works that has changed in last 10 years. Agreed though, shell changes less often than glibc; but that's merely based on time, I can imagine in some point in the future there may be no need for further changes in glibc the same way POSIX stopped changing years ago; or in other words, it got standardized to be solid. Going back from those details to OpenRC and systemd, one could say that one tool depends on old and solid standards while the other depends on new and developing technologies; there are reasons enough to choose for either. Some things are better done by A, others by B. That's not what I'm after, I want to know when either A or B doesn't work; this is a matter of 1) trying to make it work for our users and 2) documenting it to our users in which occasions it doesn't work. Though, I went to take a look, if I were to trust the systemd ebuild it seems that it doesn't work with glibc versions prior to May 2009 (2.10) so I think we're in a quite good standing here; the amount of users that don't upgrade for four years that need systemd is likely minor, hence we don't need to document this and this doesn't form a problem. Likewise if you picked a kernel from a few years ago systemd with all its use of cgroups and such probably wouldn't work, while openrc is simpler. Certainly if you picked a FreeBSD kernel systemd will not work. (Keep in mind the set of systems not using a recent linux kernel includes all systems that don't run linux at all.) I don't think the goal of making systemd more accessible has anything to do with people that don't upgrade for a few years; it doesn't stand in their way and given that it is out of the Portage tree we likely don't support these kind of practices anymore. Support is a big word and doesn't mean we don't try to help them if they have a solid case, but I can't see someone with 2006 hardware wanting to run GNOME 3.8. In any case, there really isn't any decision to make here. Then for what purpose is this discussion still going on? As long as devs want to support openrc it will be supported. Likewise with eudev. As long as devs want to support systemd and udev those will be options as well. The beauty of Gentoo is that more than any distro it maximizes the options for our users. The changes in Gnome may eliminate Gnome+openrc as a practical option, and when those teams stop supporting the combo then users will have to make a choice to not use one or the other. Gentoo is about choice, but that doesn't mean that we have to offer EVERY possible choice. If somebody wants to support my hp48 calculator as a Gentoo arch that would be great, but that doesn't mean that I can sta hassling teams to do the work for me. Gentoo is about working TOGETHER to provide choices, not about telling others to make choices work for you. That's what I'm after, I have send a very similar mail two months ago. -- With kind regards, Tom Wijsman (TomWij) Gentoo Developer E-mail address : tom...@gentoo.org GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D signature.asc Description: PGP signature
Re: [gentoo-dev] Making systemd more accessible to normal users
On Wed, May 15, 2013 at 2:11 PM, Tom Wijsman tom...@gentoo.org wrote: On Wed, 15 May 2013 13:25:11 -0400 Rich Freeman ri...@gentoo.org wrote: In any case, there really isn't any decision to make here. Then for what purpose is this discussion still going on? No comment on that... Maybe another way of saying things is that really the onus is on those who want others to change their behavior to explain why they should change. So, if you're seeking a change in behavior be up-front about what change you want. If you're not seeking a change in behavior, then there really isn't much point in going on unless it is to resist a proposed change. Personally I think a reasonable balance is: 1. Maintainers do not have to take initiative to create systemd units. (status quo) 2. Maintainers should accept contributed units from the community, even if they can't personally test them. This can be done at their convenience. (slight addition in work for maintainers) 3. Maintainers can ask users to contribute units upstream if not already done. I don't think this should be a hard requirement (ie accepting a non-upstreamed unit is not a QA violation). If upstream makes this difficult this should not be an excuse for marking bugs invalid. The goal is to work with upstream, not harass them. (some more work for bug submitters and maintainers). Bottom line - maintainers don't have to go out of their way to support systemd, but they should be friendly facilitators when others are willing to do the work. This is no different from accepting desktop entries and such even if you don't use a Freedesktop-compatible environment. Rich
Re: [gentoo-dev] Making systemd more accessible to normal users
El mié, 15-05-2013 a las 15:02 -0400, Rich Freeman escribió: [...] No comment on that... Maybe another way of saying things is that really the onus is on those who want others to change their behavior to explain why they should change. So, if you're seeking a change in behavior be up-front about what change you want. If you're not seeking a change in behavior, then there really isn't much point in going on unless it is to resist a proposed change. Personally I think a reasonable balance is: 1. Maintainers do not have to take initiative to create systemd units. (status quo) 2. Maintainers should accept contributed units from the community, even if they can't personally test them. This can be done at their convenience. (slight addition in work for maintainers) 3. Maintainers can ask users to contribute units upstream if not already done. I don't think this should be a hard requirement (ie accepting a non-upstreamed unit is not a QA violation). If upstream makes this difficult this should not be an excuse for marking bugs invalid. The goal is to work with upstream, not harass them. (some more work for bug submitters and maintainers). Bottom line - maintainers don't have to go out of their way to support systemd, but they should be friendly facilitators when others are willing to do the work. This is no different from accepting desktop entries and such even if you don't use a Freedesktop-compatible environment. Rich +1
Re: [gentoo-dev] Making systemd more accessible to normal users
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 15/05/13 17:10, Luca Barbato wrote: Those that can't use systemd: - those not using a recent linux kernel And let's not forget those who aren't using Linux at all. - -- Alexander alexan...@plaimi.net http://plaimi.net/~alexander -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iF4EAREIAAYFAlGT9nUACgkQRtClrXBQc7UHiQD/R07lH+0F6ZARoODe2efrMVii w5Ok3kTjChpjkvLKjt8BAJIh8Rt+wmljyfT+yjj3WY2BfFWx4Vxkt2lom6V4G0A/ =NqLn -END PGP SIGNATURE-
Re: [gentoo-dev] Making systemd more accessible to normal users
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wed, 15 May 2013 22:56:21 +0200 Alexander Berntsen alexan...@plaimi.net wrote: On 15/05/13 17:10, Luca Barbato wrote: Those that can't use systemd: - those not using a recent linux kernel And let's not forget those who aren't using Linux at all. Why not? - -- Ciaran McCreesh -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) iEYEARECAAYFAlGT98MACgkQ96zL6DUtXhHnPACgqIhmnyvutdvIw0ijl4ralYyz cwMAn24EP4lpA/jHAdxAv6lx2e74qxy6 =68cT -END PGP SIGNATURE-
Re: [gentoo-dev] Making systemd more accessible to normal users
On Wed, May 15, 2013 at 03:41:31PM +0200, Fabio Erculiani wrote Are we realizing that in order to keep systemd out of our way, we're currently writing and maintaining drop-in replacements for the features that systemd is already providing in an actively maintained state? openrc-settingsd was the first thing that we as Gentoo developers (Pacho?) had to write in order to merge GNOME 3.6 into our tree. So Redhat, who are heavily into GNOME ( http://fedoraproject.org/wiki/Red_Hat_contributions#GNOME_developers ) decided to make GNOME depend on other Redhat-developed software (systemd and pulseadio). Well... like... do... Question... when Sun made OpenOffice depend on Java (also a Sun product) did Gentoo developers run around suggesting that Java be made a part of the core Gentoo base system? I don't think so. If a user wants to run GNOME badly enough, he'll switch to systemd. I don't see why the rest of us (i.e. non-users of GNOME) should have to follow along and reconfigure our systems. This is a case of the tail wagging the dog. So what do we want to do then? Isolate from the rest of the world? (It's not a sarcastic question). I hope that everybody does their own reality check. You are effectively calling not-using-GNOME isolationist. Let's just say I disagree with you on that. BTW, see my sig. -- Walter Dnes waltd...@waltdnes.org I don't run desktop environments; I run useful applications
Re: [gentoo-dev] Making systemd more accessible to normal users
On Wed, May 15, 2013 at 2:18 PM, waltd...@waltdnes.org wrote: Question... when Sun made OpenOffice depend on Java (also a Sun product) did Gentoo developers run around suggesting that Java be made a part of the core Gentoo base system? I don't think so. If a user wants to run GNOME badly enough, he'll switch to systemd. I don't see why the rest of us (i.e. non-users of GNOME) should have to follow along and reconfigure our systems. This is a case of the tail wagging the dog. It will probably be more than a decade before anybody is FORCED to run systemd on Gentoo. You don't even have to run udev on Gentoo. It will probably be years before the default even changes, assuming the trajectory of systemd remains as it seems to be. I think people are really getting carried away here. I believe the udev team generally wants to follow upstream udev, and there is eudev and busybox mdev for those who don't want that. No distro provides so many ways of avoiding systemd. I don't see that changing anytime soon. This thread just started out asking maintainers to commit unit files when asked, that's all. Anybody who doesn't want them can mask them. If anybody feels eudev/openrc/whatever isn't progressing enough they can contribute improvements to these packages, or pay somebody else to do it for them. Developers work on what they want to work on. If no devs can be bothered with systemd then it will die on the vine, and if no developers choose to work on openrc the same will happen there. Either is unlikely, though the market share of either is likely to change over time. Rich
Re: [gentoo-dev] Making systemd more accessible to normal users
On 05/15/13 16:01, Ciaran McCreesh wrote: On Wed, 15 May 2013 22:56:21 +0200 Alexander Berntsen alexan...@plaimi.net wrote: On 15/05/13 17:10, Luca Barbato wrote: Those that can't use systemd: - those not using a recent linux kernel And let's not forget those who aren't using Linux at all. Why not? Troll mode engaged? -- -- Matthew Thode (prometheanfire) signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Making systemd more accessible to normal users
On Wed, May 15, 2013 at 06:38:14PM -0400, Rich Freeman wrote It will probably be more than a decade before anybody is FORCED to run systemd on Gentoo. You don't even have to run udev on Gentoo. It will probably be years before the default even changes, assuming the trajectory of systemd remains as it seems to be. I think people are really getting carried away here. I believe the udev team generally wants to follow upstream udev, and there is eudev and busybox mdev for those who don't want that. No distro provides so many ways of avoiding systemd. I don't see that changing anytime soon. I was replyiny to a poster who said... at some near point in the future, our users will be forced to replace udev/eudev with systemd. Like it. Or not. You mentioned that it will be years before it happens. I realize that this borders on the political, but if nobody objects *NOW*, in a couple of years it'll happen. And the developers will say but nobody objected. You're right that the process takes time. It's precisely because of that that unhappy users need to make their feelings known now before it's too late. -- Walter Dnes waltd...@waltdnes.org I don't run desktop environments; I run useful applications
Re: [gentoo-dev] Making systemd more accessible to normal users
On Wed, May 15, 2013 at 10:16:01PM +0800, Ben de Groot wrote: We don't control upstreams, but we still have choices. At this point I only see Gnome and udev upstreams who are forcing their users to use systemd. (There may be other projects too that I'm not aware of.) Udev doesn't force anything. In fact upstream makes it clear that udev can be run without systemd. William signature.asc Description: Digital signature
Re: [gentoo-dev] Making systemd more accessible to normal users
On Wed, May 15, 2013 at 10:56:21PM +0200, Alexander Berntsen wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 15/05/13 17:10, Luca Barbato wrote: Those that can't use systemd: - those not using a recent linux kernel And let's not forget those who aren't using Linux at all. I'm not really sure how relevant this is, because we can set up different default init systems based on the operating system in our tree easily enough. If we decide in the future to make the default init system on linux systemd, it is simple enough to make it OpenRC or whatever else on *bsd. William signature.asc Description: Digital signature
Re: [gentoo-dev] Making systemd more accessible to normal users
On Wed, May 15, 2013 at 02:18:13PM -0400, waltd...@waltdnes.org wrote: On Wed, May 15, 2013 at 03:41:31PM +0200, Fabio Erculiani wrote Are we realizing that in order to keep systemd out of our way, we're currently writing and maintaining drop-in replacements for the features that systemd is already providing in an actively maintained state? openrc-settingsd was the first thing that we as Gentoo developers (Pacho?) had to write in order to merge GNOME 3.6 into our tree. So Redhat, who are heavily into GNOME ( http://fedoraproject.org/wiki/Red_Hat_contributions#GNOME_developers ) decided to make GNOME depend on other Redhat-developed software (systemd and pulseadio). Well... like... do... Question... when Sun made OpenOffice depend on Java (also a Sun product) did Gentoo developers run around suggesting that Java be made a part of the core Gentoo base system? I don't think so. If a user wants to run GNOME badly enough, he'll switch to systemd. I don't see why the rest of us (i.e. non-users of GNOME) should have to follow along and reconfigure our systems. This is a case of the tail wagging the dog. I don't interpret what he is saying that way. I think what he is talking about is that we are trying to get teams to support non-systemd setups when upstreams do not, like with gnome. Gnome now has a hard dependency on systemd (for gnome newer than 3.8). Some folks want to use gnome without systemd and are putting that under the gentoo is about choice banner and want us to support them. So what do we want to do then? Isolate from the rest of the world? (It's not a sarcastic question). I hope that everybody does their own reality check. You are effectively calling not-using-GNOME isolationist. Let's just say I disagree with you on that. BTW, see my sig. See above. William signature.asc Description: Digital signature
Re: [gentoo-dev] Making systemd more accessible to normal users
On 05/15/13 19:27, William Hubbs wrote: On Wed, May 15, 2013 at 10:16:01PM +0800, Ben de Groot wrote: We don't control upstreams, but we still have choices. At this point I only see Gnome and udev upstreams who are forcing their users to use systemd. (There may be other projects too that I'm not aware of.) Udev doesn't force anything. In fact upstream makes it clear that udev can be run without systemd. William so then we should decouple logind from udev downstream (packaging) :D -- -- Matthew Thode (prometheanfire) signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Making systemd more accessible to normal users
On 05/15/13 20:20, William Hubbs wrote: On Wed, May 15, 2013 at 02:18:13PM -0400, waltd...@waltdnes.org wrote: On Wed, May 15, 2013 at 03:41:31PM +0200, Fabio Erculiani wrote Are we realizing that in order to keep systemd out of our way, we're currently writing and maintaining drop-in replacements for the features that systemd is already providing in an actively maintained state? openrc-settingsd was the first thing that we as Gentoo developers (Pacho?) had to write in order to merge GNOME 3.6 into our tree. So Redhat, who are heavily into GNOME ( http://fedoraproject.org/wiki/Red_Hat_contributions#GNOME_developers ) decided to make GNOME depend on other Redhat-developed software (systemd and pulseadio). Well... like... do... Question... when Sun made OpenOffice depend on Java (also a Sun product) did Gentoo developers run around suggesting that Java be made a part of the core Gentoo base system? I don't think so. If a user wants to run GNOME badly enough, he'll switch to systemd. I don't see why the rest of us (i.e. non-users of GNOME) should have to follow along and reconfigure our systems. This is a case of the tail wagging the dog. I don't interpret what he is saying that way. I think what he is talking about is that we are trying to get teams to support non-systemd setups when upstreams do not, like with gnome. Gnome now has a hard dependency on systemd (for gnome newer than 3.8). Some folks want to use gnome without systemd and are putting that under the gentoo is about choice banner and want us to support them. So what do we want to do then? Isolate from the rest of the world? (It's not a sarcastic question). I hope that everybody does their own reality check. You are effectively calling not-using-GNOME isolationist. Let's just say I disagree with you on that. BTW, see my sig. See above. William If upstream gnome has that dep on systemd then I kinda think we should too (technical decision, not one I like personally) -- -- Matthew Thode (prometheanfire) signature.asc Description: OpenPGP digital signature
Re: Re: [gentoo-dev] Making systemd more accessible to normal users
On 05/15/2013 08:41 AM, Fabio Erculiani wrote: Are we realizing that in order to keep systemd out of our way, we're currently writing and maintaining drop-in replacements for the features that systemd is already providing in an actively maintained state? openrc-settingsd was the first thing that we as Gentoo developers (Pacho?) had to write in order to merge GNOME 3.6 into our tree. And now that GNOME 3.8 is out, the game starts over again: logind is a hard requirement, logind is part of systemd, starting logind (which replaces consolekit) is not that trivial as you may think (and is the thing I started to work on anyway). And if this wasn't enough, it means that if you want GNOME 3.8, you need to get logind, which may or not may get included in our udev ebuild and if it won't, it means that you will be forced to use systemd as device manager if you want GNOME 3.8, which is believe it or not, the thing that Ubuntu did. The problem will only increase in size as the clock moves. And (and!) how does all this fit together with eudev? If the idea is to either put logind in udev (thus, not creating a separate logind ebuild), it means that eudev is already a dead end for GNOME users, unless the eudev team is going to provide logind as well. I don't want to start a flamewar here, I was the one who called Lennart software lennartware, but science is science, and a reality check had to be done: at some near point in the future, our users will be forced to replace udev/eudev with systemd. Like it. Or not. While I successfully use both openrc and systemd, I _do_ think that (and expect to see) more and more users (and developers) will be switching to systemd. Is there anything we can do? Besides being prepared, I don't think so. Do we control upstreams? No, sorry. So what do we want to do then? Isolate from the rest of the world? (It's not a sarcastic question). I hope that everybody does their own reality check. The solution is to pressure upstreams not to depend on a specific init system in order to function. How many pieces of software depend on SysV, runit, openrc, or upstart? The only ones I can think of are the pieces that are designed specifically for making those init systems easier to administer, not user-facing software like desktop environments. I sincerely believe that each user and distro reserves the right to choose which software to boot the system with, and desktop environments and other user-facing software should not care about which init system it's running on. In the case of GNOME, I think they're going too far by depending on these things. GNOME devs haven't cared much for user responses (especially wrt GTK+ 3.x), so they are likely to continue integration with systemd. They're free to, but we're free to not use it, too. Personally, I will not have systemd on my box(es). I don't agree with its motives, its methods, or its design. I will not use software that depends on it. If the situation gets bad enough, then I may be forced to switch to another OS... that bothers me, to a degree, but as long as it's on my hardware, I have a say. It would not bother me if distros ostracized Lennart and his projects from the free software world, as he approaches free software with a toxic attitude. We wouldn't miss much IMO. As for Gentoo itself, I'm happy as long as choice remains the governing principle.
Re: [gentoo-dev] Making systemd more accessible to normal users
On 05/15/2013 07:26 PM, Tom Wijsman wrote: On Wed, 15 May 2013 17:03:13 +0200 Luca Barbato lu_z...@gentoo.org wrote: On 05/15/2013 03:41 PM, Fabio Erculiani wrote: ... GNOME ... And given that the end-plan according to the guys is to kill the distributions shall we just close Gentoo now? Let's not exaggerate things, there are a ton of other DEs out there; are all of them starting to depend on systemd specific features? Luckily not, yet _that_'s what is in the roadmap apparently. Whether or not it is terrible, it is a time sink; is it worth doing it? For any non-linux, less-than-3.x-linux, non-glibc system user probably. Indeed, the goal here is solely to make systemd more accessible; we shouldn't pursue it to be the main init system or force it upon users, unless there are indicators in the future that it became better (eg. supports BSD, ...) for everyone. And that has my support, there is disagreement on what that entitles. Used GNOME for months, then with 3.6 - 3.8 it started to break on me; it didn't work on either OpenRC or systemd. While I was a happy user at first, recent events made me lose interest in it; I think a discussion regarding init systems and similar software shouldn't be focused on a single DE, so I too am not sure why focus is laid on GNOME here... Since it is the DE forcing all those changes down distribution throats. lu
Re: [gentoo-dev] Making systemd more accessible to normal users
On 05/10/2013 09:45 AM, Ralph Sennhauser wrote: [1] http://fedoraproject.org/wiki/Packaging:Systemd#Unit_Files What if openrc/upstart/runit devs start harassing upstream in the same way? Strategically is great, but isn't exactly something nice to do. Probably people caring about alternatives should start bothering upstreams likewise and we'll see how it goes. I'm sure that *everybody* would be delighted to provide those 4-5 different initscripts because one distribution or the other wants others do the work for them... I'm saying again that trying to get a good intermediate representation and have a generator (eselect based maybe) provide the init-specific file would be much better. In the end initscripts are usually distribution dependent since they are an integration step. lu
Re: [gentoo-dev] Making systemd more accessible to normal users
On Fri, 10 May 2013 06:09:32 -0400 Rich Freeman ri...@gentoo.org wrote: On Fri, May 10, 2013 at 3:45 AM, Ralph Sennhauser s...@gentoo.org wrote: The other thing is those unit files really should come from upstream and other distributions urge their developers to work with upstream [1] Therefore I'd require an upstream bug for each unit that we add. Makes sense, though I wouldn't necessarily make it a hard requirement. Also, upstream units may not be usable as-is. They might reference incorrect file locations (though I'd hope not for the most part), and in particular dependency naming will always be a challenge. Adopting a package to distribution specifics is perfectly valid. But here it's about adding functionality to a package that wasn't there before. The usual reaction in such situations is to tell users to bug upstream about it first. Upstream rejection of a unit should certainly not lead to Gentoo rejection of a unit, any more than their rejection of a script for OpenRC should. Upstreams will likely be slow to embrace the init-scripts-aren't-just-for-distros thing. Rich If an upstream bug is filed and upstream says fuck off there is still a bug report which would meet the requirement. Maybe some other distro even filed the bug already for us.
Re: [gentoo-dev] Making systemd more accessible to normal users
On Sat, May 11, 2013 at 12:55 PM, Ralph Sennhauser s...@gentoo.org wrote: Adopting a package to distribution specifics is perfectly valid. But here it's about adding functionality to a package that wasn't there before. The usual reaction in such situations is to tell users to bug upstream about it first. Adding an init.d script is hardly adding functionality - it is merely making the package functional at all. If an upstream bug is filed and upstream says fuck off there is still a bug report which would meet the requirement. Maybe some other distro even filed the bug already for us. I agree that it is a good practice, but it isn't a requirement. We don't even require package maintainers to submit bugfix patches upstream, let alone init scripts. Maintainers should certainly be encouraged to do so, but it seems like we have enough trouble following rules like don't touch packages you don't maintain, fail to test them, and end up breaking them. Rich
Re: [gentoo-dev] Making systemd more accessible to normal users
On Wed, 8 May 2013 13:37:51 -0400 Rich Freeman ri...@gentoo.org wrote: Bottom line is that none of this should really be inconveniencing maintainers much - nobody is required to create unit files. However, if a friendly user submits a bug with one attached, then the maintainer should strongly consider adding them to the package at the next convenient time. Indeed no maintainer should be bothered with having his package install a unit file, though two points. A maintainer usually dislikes adding something contributed by a user that he doesn't know about / can't verify . So letting systemd herd picking unit files and committing them I think is reasonable. The chance for screwing with a package by just adding the unit file are close to zero even if not familiar with the package. The other thing is those unit files really should come from upstream and other distributions urge their developers to work with upstream [1] Therefore I'd require an upstream bug for each unit that we add. [1] http://fedoraproject.org/wiki/Packaging:Systemd#Unit_Files
Re: [gentoo-dev] Making systemd more accessible to normal users
On Fri, May 10, 2013 at 3:45 AM, Ralph Sennhauser s...@gentoo.org wrote: The other thing is those unit files really should come from upstream and other distributions urge their developers to work with upstream [1] Therefore I'd require an upstream bug for each unit that we add. Makes sense, though I wouldn't necessarily make it a hard requirement. Also, upstream units may not be usable as-is. They might reference incorrect file locations (though I'd hope not for the most part), and in particular dependency naming will always be a challenge. Upstream rejection of a unit should certainly not lead to Gentoo rejection of a unit, any more than their rejection of a script for OpenRC should. Upstreams will likely be slow to embrace the init-scripts-aren't-just-for-distros thing. Rich
Re: [gentoo-dev] Making systemd more accessible to normal users
On 05/08/2013 10:01 PM, Jeroen Roovers wrote: On Wed, 8 May 2013 21:48:36 -0400 Walter Dnes waltd...@waltdnes.org wrote: Wouldn't the systemd USE flag be the appropriate one to key on? The description in /usr/portage/profiles/use.desc says... systemd - Enable use of systemd-specific libraries and features like socket activation or session tracking Surely, units files qualify as systemd-specific features. https://bugs.gentoo.org/show_bug.cgi?id=198901 jer People keep saying disk space is not an issue but it is on embedded systems. Even 4k or one i-node. So the choice to not install unit files is important. I'm sympathetic to the idea of reducing use flags and I would really not like to see USE=openrc or systemd everywhere. Without having tested, it does seem that INSTALL_MASK is sufficient. I recommend going that route and documenting it. -- Anthony G. Basile, Ph. D. Chair of Information Technology D'Youville College Buffalo, NY 14201 (716) 829-8197
Re: [gentoo-dev] Making systemd more accessible to normal users
On Wed, May 8, 2013 at 10:18 PM, Walter Dnes waltd...@waltdnes.org wrote: On Wed, May 08, 2013 at 10:31:21PM +0530, Arun Raghavan wrote The overhead of the files' presence is trivial, and most users won't care. Those who do care have a trivial line to add in make.conf, and that is for the small number of people who share your vitriol for the systemd project. Then howsabout a units ebuild that installs all available units files for systemd users? The overhead of the files' presence is trivial, and most systemd users won't care. Read the rest of the thread and the archives. Both suggestions have been discussed and they're not practical. Your first suggestion was specifically rejected by the council. Your second one was suggested only yesterday in this very same thread. The thread title says it all... normal Gentoo users don't use systemd. There is no such thing as a normal Gentoo user. About the closest you'll come is a hypothetical Gentoo user who doesn't touch /etc/portage. I suspect that the time will be approaching soon that there will be more development/testing targeting systemd than OpenRC on Gentoo. I'm sure the default will remain as-is for a long-time. For how many years was the typical developer running OpenRC while the typical user was running baselayout 1? The goal is to make systemd a first class citizen in Gentoo, nothing more. Developers will not be required to run it, or test on it, just as they aren't required to run or test on OpenRC or FreeBSD (two other first-class citizens in Gentoo). If you don't want unit files installed, just use INSTALL_MASK as endorsed by the Council. Ditto for docs, or init.d files, or whatever. Rich
Re: [gentoo-dev] Making systemd more accessible to normal users
On Thu, May 9, 2013 at 12:44 PM, Michał Górny mgo...@gentoo.org wrote: We should probably consider extending the INSTALL_MASK a bit. A good idea would be to allow repositories to pre-define names for INSTALL_MASK (alike USE flags) and allow portage to control them over those names. We'd need a corresponding way to unmask stuff as well, if we went that route. It would add value for stuff like the embedded profile, but I wouldn't want to see it used in the base profiles. Rich
Re: [gentoo-dev] Making systemd more accessible to normal users
El jue, 09-05-2013 a las 18:44 +0200, Michał Górny escribió:
[...]
A similar variant is implemented in app-portage/install-mask which maps
names obtained from ${FILESDIR} to paths.
Didn't know that utility :O, thanks! (maybe, at least, a blog entry
could have been added when you did this tool ;))
Re: [gentoo-dev] Making systemd more accessible to normal users
On 1 May 2013 18:04, Fabio Erculiani lx...@gentoo.org wrote: It looks like there is some consensus on the effort of making systemd more accessible, while there are problems with submitting bugs about new systemd units of the sort that maintainers just_dont_answer(tm). In this case, I am just giving 3 weeks grace period for maintainers to answer and then I usually go ahead adding units (I'm in systemd@ after all). In my opinion you should not be asking maintainers to add systemd units to their packages. They most likely do not have systems on which they can test these, and very few users would need them anyway. I would think it is better to add them to a separate systemd-units package. -- Cheers, Ben | yngwin Gentoo developer Gentoo Qt project lead, Gentoo Wiki admin
Re: [gentoo-dev] Making systemd more accessible to normal users
On Wed, May 8, 2013 at 5:26 PM, Ben de Groot yng...@gentoo.org wrote: On 1 May 2013 18:04, Fabio Erculiani lx...@gentoo.org wrote: It looks like there is some consensus on the effort of making systemd more accessible, while there are problems with submitting bugs about new systemd units of the sort that maintainers just_dont_answer(tm). In this case, I am just giving 3 weeks grace period for maintainers to answer and then I usually go ahead adding units (I'm in systemd@ after all). In my opinion you should not be asking maintainers to add systemd units to their packages. They most likely do not have systems on which they can test these, and very few users would need them anyway. I would think it is better to add them to a separate systemd-units package. This sounds really wrong (tm) to me. It took me two weeks to kill that silly systemd-units pkg. All the distros around here do install systemd units with their packages and I believe that the council has already spoken about this. -- Cheers, Ben | yngwin Gentoo developer Gentoo Qt project lead, Gentoo Wiki admin -- Fabio Erculiani
Re: [gentoo-dev] Making systemd more accessible to normal users
Ben de Groot schrieb: On 1 May 2013 18:04, Fabio Erculiani lx...@gentoo.org wrote: It looks like there is some consensus on the effort of making systemd more accessible, while there are problems with submitting bugs about new systemd units of the sort that maintainers just_dont_answer(tm). In this case, I am just giving 3 weeks grace period for maintainers to answer and then I usually go ahead adding units (I'm in systemd@ after all). In my opinion you should not be asking maintainers to add systemd units to their packages. They most likely do not have systems on which they can test these, and very few users would need them anyway. I would think it is better to add them to a separate systemd-units package. Note that a similar thing is already done with the selinux policy packages. Mostly the complaints against adding systemd units are that it would unnecessarily clutter non-systemd installs. Users who complain are told to set INSTALL_MASK but that is somewhat unwieldy. A separate package for the unit file would solve this problem nicely. Another option would be to add a dounit command to a future EAPI (like doinitd today) and make portage install them unless FEATURES=nounit (like nodoc/noinfo/noman today). Best regards, Chí-Thanh Christopher Nguyễn
Re: [gentoo-dev] Making systemd more accessible to normal users
On 8 May 2013 23:39, Fabio Erculiani lx...@gentoo.org wrote: On Wed, May 8, 2013 at 5:26 PM, Ben de Groot yng...@gentoo.org wrote: On 1 May 2013 18:04, Fabio Erculiani lx...@gentoo.org wrote: It looks like there is some consensus on the effort of making systemd more accessible, while there are problems with submitting bugs about new systemd units of the sort that maintainers just_dont_answer(tm). In this case, I am just giving 3 weeks grace period for maintainers to answer and then I usually go ahead adding units (I'm in systemd@ after all). In my opinion you should not be asking maintainers to add systemd units to their packages. They most likely do not have systems on which they can test these, and very few users would need them anyway. I would think it is better to add them to a separate systemd-units package. This sounds really wrong (tm) to me. It took me two weeks to kill that silly systemd-units pkg. All the distros around here do install systemd units with their packages and I believe that the council has already spoken about this. It sounds more wrong to me to be asking normal package maintainers to test and maintain unit files, while they don't use systemd themselves, nor have it installed. Nor would most of our users need this. And I believe the council has only spoken out against using a useflag for installing such files. Afaik they haven't spoken out against a systemd-units package. Please refer me to their decision if I'm wrong. -- Cheers, Ben | yngwin Gentoo developer Gentoo Qt project lead, Gentoo Wiki admin
Re: [gentoo-dev] Making systemd more accessible to normal users
On Wed, May 8, 2013 at 5:39 PM, Chí-Thanh Christopher Nguyễn chith...@gentoo.org wrote: Ben de Groot schrieb: On 1 May 2013 18:04, Fabio Erculiani lx...@gentoo.org wrote: It looks like there is some consensus on the effort of making systemd more accessible, while there are problems with submitting bugs about new systemd units of the sort that maintainers just_dont_answer(tm). In this case, I am just giving 3 weeks grace period for maintainers to answer and then I usually go ahead adding units (I'm in systemd@ after all). In my opinion you should not be asking maintainers to add systemd units to their packages. They most likely do not have systems on which they can test these, and very few users would need them anyway. I would think it is better to add them to a separate systemd-units package. Note that a similar thing is already done with the selinux policy packages. Upstreams will _DO_ ship systemd units at some point in future. It's a completely different thing. Don't compare oranges to apples. Mostly the complaints against adding systemd units are that it would unnecessarily clutter non-systemd installs. Users who complain are told to set INSTALL_MASK but that is somewhat unwieldy. Cluttering a system by just installing 4kb files? The council has spoken. If you don't like the decision, I am sorry. I can say the same for init scripts, they are freaking cluttering my system and they're all over. Or perhaps all these man pages, I don't need man pages locally but still most ebuilds do install them. What do we do? Let's be serious here. A separate package for the unit file would solve this problem nicely. No, it will generate a gazillion of other problems. Like conflicts arising every single day, just to name one. Is that hard to do it right, as everybody else in this world does, and move on? Another option would be to add a dounit command to a future EAPI (like doinitd today) and make portage install them unless FEATURES=nounit (like nodoc/noinfo/noman today). Why all this mess!? Best regards, Chí-Thanh Christopher Nguyễn -- Fabio Erculiani
Re: [gentoo-dev] Making systemd more accessible to normal users
On 05/08/2013 11:39 AM, Chí-Thanh Christopher Nguyễn wrote: Ben de Groot schrieb: On 1 May 2013 18:04, Fabio Erculiani lx...@gentoo.org wrote: It looks like there is some consensus on the effort of making systemd more accessible, while there are problems with submitting bugs about new systemd units of the sort that maintainers just_dont_answer(tm). In this case, I am just giving 3 weeks grace period for maintainers to answer and then I usually go ahead adding units (I'm in systemd@ after all). In my opinion you should not be asking maintainers to add systemd units to their packages. They most likely do not have systems on which they can test these, and very few users would need them anyway. I would think it is better to add them to a separate systemd-units package. Note that a similar thing is already done with the selinux policy packages. Mostly the complaints against adding systemd units are that it would unnecessarily clutter non-systemd installs. Users who complain are told to set INSTALL_MASK but that is somewhat unwieldy. A separate package for the unit file would solve this problem nicely. Correct me if I'm wrong, but isn't your average ebuild file larger than your average systemd unit file? Another option would be to add a dounit command to a future EAPI (like doinitd today) and make portage install them unless FEATURES=nounit (like nodoc/noinfo/noman today). I'm beginning to warm up to the idea of replacing most init scripts with systemd unit files and a unit-init converter. This is obviously nonsense if upstream provides init scripts, but I'm unsure how common that is. (or even could be) signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Making systemd more accessible to normal users
On Wed, May 8, 2013 at 5:49 PM, Ben de Groot yng...@gentoo.org wrote: On 8 May 2013 23:39, Fabio Erculiani lx...@gentoo.org wrote: On Wed, May 8, 2013 at 5:26 PM, Ben de Groot yng...@gentoo.org wrote: On 1 May 2013 18:04, Fabio Erculiani lx...@gentoo.org wrote: It looks like there is some consensus on the effort of making systemd more accessible, while there are problems with submitting bugs about new systemd units of the sort that maintainers just_dont_answer(tm). In this case, I am just giving 3 weeks grace period for maintainers to answer and then I usually go ahead adding units (I'm in systemd@ after all). In my opinion you should not be asking maintainers to add systemd units to their packages. They most likely do not have systems on which they can test these, and very few users would need them anyway. I would think it is better to add them to a separate systemd-units package. This sounds really wrong (tm) to me. It took me two weeks to kill that silly systemd-units pkg. All the distros around here do install systemd units with their packages and I believe that the council has already spoken about this. It sounds more wrong to me to be asking normal package maintainers to test and maintain unit files, while they don't use systemd themselves, nor have it installed. Nor would most of our users need this. Nobody is asking maintainers to test units. The systemd team is responsible for them. And I believe the council has only spoken out against using a useflag for installing such files. Afaik they haven't spoken out against a systemd-units package. Please refer me to their decision if I'm wrong. I was referring to that. We never mentioned a possible systemd-units package in any council meeting I believe. I hardly believe that the systemd team would accept such choice. -- Cheers, Ben | yngwin Gentoo developer Gentoo Qt project lead, Gentoo Wiki admin -- Fabio Erculiani
Re: [gentoo-dev] Making systemd more accessible to normal users
On Wed, May 8, 2013 at 11:49 AM, Ben de Groot yng...@gentoo.org wrote: On 8 May 2013 23:39, Fabio Erculiani lx...@gentoo.org wrote: On Wed, May 8, 2013 at 5:26 PM, Ben de Groot yng...@gentoo.org wrote: On 1 May 2013 18:04, Fabio Erculiani lx...@gentoo.org wrote: It looks like there is some consensus on the effort of making systemd more accessible, while there are problems with submitting bugs about new systemd units of the sort that maintainers just_dont_answer(tm). In this case, I am just giving 3 weeks grace period for maintainers to answer and then I usually go ahead adding units (I'm in systemd@ after all). In my opinion you should not be asking maintainers to add systemd units to their packages. They most likely do not have systems on which they can test these, and very few users would need them anyway. I would think it is better to add them to a separate systemd-units package. This sounds really wrong (tm) to me. It took me two weeks to kill that silly systemd-units pkg. All the distros around here do install systemd units with their packages and I believe that the council has already spoken about this. It sounds more wrong to me to be asking normal package maintainers to test and maintain unit files, while they don't use systemd themselves, nor have it installed. Nor would most of our users need this. I don't think we are actually asking you to test/maintain them; you can treat them as a request for permission to perform a non-maintainer commit. If users run into problems, please feel free to copy/assign us on bugs. And I believe the council has only spoken out against using a useflag for installing such files. Afaik they haven't spoken out against a systemd-units package. Please refer me to their decision if I'm wrong. Having a package to install every systemd unit in existence just clutters the end user's system and makes it harder to tell which units are actually valid. Also, if a unit needs to be updated between versions of a given package, that will lead to some strange looking deps. A potential alternative would be to have a separate systemd-unit package for each package in the tree, but that just seems like overkill to me for a set of very small text files. And it still means adding an optional runtime dep to the relevent packages.
Re: [gentoo-dev] Making systemd more accessible to normal users
Fabio Erculiani schrieb: Or perhaps all these man pages, I don't need man pages locally but still most ebuilds do install them. What do we do? Users who don't want them set FEATURES=noman. Let's be serious here. I assure you that I am fully serious. Another option would be to add a dounit command to a future EAPI (like doinitd today) and make portage install them unless FEATURES=nounit (like nodoc/noinfo/noman today). Why all this mess!? Please elaborate why you think that a dounit command is a mess. Best regards, Chí-Thanh Christopher Nguyễn
Re: [gentoo-dev] Making systemd more accessible to normal users
On Wed, May 8, 2013 at 12:06 PM, Chí-Thanh Christopher Nguyễn chith...@gentoo.org wrote: Fabio Erculiani schrieb: Or perhaps all these man pages, I don't need man pages locally but still most ebuilds do install them. What do we do? Users who don't want them set FEATURES=noman. Let's be serious here. I assure you that I am fully serious. Another option would be to add a dounit command to a future EAPI (like doinitd today) and make portage install them unless FEATURES=nounit (like nodoc/noinfo/noman today). Why all this mess!? Please elaborate why you think that a dounit command is a mess. A working solution right now would be to set INSTALL_MASK=/usr/lib/systemd/*. If you want to formalize this into a portage feature, I have no objection. The problem with a helper function is that it would miss cases where the upstream build system actually installs the units.
Re: [gentoo-dev] Making systemd more accessible to normal users
On 8 May 2013 23:49, Fabio Erculiani lx...@gentoo.org wrote: On Wed, May 8, 2013 at 5:39 PM, Chí-Thanh Christopher Nguyễn chith...@gentoo.org wrote: Ben de Groot schrieb: On 1 May 2013 18:04, Fabio Erculiani lx...@gentoo.org wrote: It looks like there is some consensus on the effort of making systemd more accessible, while there are problems with submitting bugs about new systemd units of the sort that maintainers just_dont_answer(tm). In this case, I am just giving 3 weeks grace period for maintainers to answer and then I usually go ahead adding units (I'm in systemd@ after all). In my opinion you should not be asking maintainers to add systemd units to their packages. They most likely do not have systems on which they can test these, and very few users would need them anyway. I would think it is better to add them to a separate systemd-units package. Note that a similar thing is already done with the selinux policy packages. Upstreams will _DO_ ship systemd units at some point in future. It's a completely different thing. Don't compare oranges to apples. Where upstreams ship systemd units, I don't think there is any issue. The problem is you are asking Gentoo maintainers to add unit files that upstream is not shipping. In this case we should test and maintain these ourselves, which is an additional burden for very little (if any) gain. Mostly the complaints against adding systemd units are that it would unnecessarily clutter non-systemd installs. Users who complain are told to set INSTALL_MASK but that is somewhat unwieldy. Cluttering a system by just installing 4kb files? The council has spoken. If you don't like the decision, I am sorry. I can say the same for init scripts, they are freaking cluttering my system and they're all over. Or perhaps all these man pages, I don't need man pages locally but still most ebuilds do install them. What do we do? Let's be serious here. You are forgetting that OpenRC is, and will remain for the foreseeable future, the default on Gentoo. Any systemd related files are completely useless for most of our users. And those of us who consider systemd a cancer do not want to see such files installed at all. Gentoo is about choice and configurability. This means we will accommodate both sides: so those who want to use an alternative init system can do so, and those who want to avoid it can also keep doing so. A separate package for the unit file would solve this problem nicely. No, it will generate a gazillion of other problems. Like conflicts arising every single day, just to name one. I think you are making the problem bigger than it is. Are there really that many packages that need a unit file, but upstream doesn't ship them yet, and many that are in the process of changing that? Either way, it should be an easy fix for systemd enthusiasts. Is that hard to do it right, as everybody else in this world does, and move on? Gentoo is different. If we should do what everybody else does, then there is no reason for our existence. Another option would be to add a dounit command to a future EAPI (like doinitd today) and make portage install them unless FEATURES=nounit (like nodoc/noinfo/noman today). Why all this mess!? You know very well why. -- Cheers, Ben | yngwin Gentoo developer Gentoo Qt project lead, Gentoo Wiki admin
Re: [gentoo-dev] Making systemd more accessible to normal users
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 08/05/13 11:49 AM, Ben de Groot wrote: On 8 May 2013 23:39, Fabio Erculiani lx...@gentoo.org wrote: On Wed, May 8, 2013 at 5:26 PM, Ben de Groot yng...@gentoo.org wrote: On 1 May 2013 18:04, Fabio Erculiani lx...@gentoo.org wrote: It looks like there is some consensus on the effort of making systemd more accessible, while there are problems with submitting bugs about new systemd units of the sort that maintainers just_dont_answer(tm). In this case, I am just giving 3 weeks grace period for maintainers to answer and then I usually go ahead adding units (I'm in systemd@ after all). In my opinion you should not be asking maintainers to add systemd units to their packages. They most likely do not have systems on which they can test these, and very few users would need them anyway. I would think it is better to add them to a separate systemd-units package. This sounds really wrong (tm) to me. It took me two weeks to kill that silly systemd-units pkg. All the distros around here do install systemd units with their packages and I believe that the council has already spoken about this. It sounds more wrong to me to be asking normal package maintainers to test and maintain unit files, while they don't use systemd themselves, nor have it installed. Nor would most of our users need this. I am generally in agreement with this. If the systemd unit file is provided by upstream, then i think it's absolutely reasonable for the gentoo dev to be expected to package it along with everything else, however if the systemd unit file is NOT included from upstream, and the gentoo dev doesn't have any experience with systemd nor any test bed to maintain the script, then expecting or requiring them to include it is not reasonable to me imo. If they optionally want to anyways, of course, more power to them, and there's probably no reason not to have a bug filed about it (at say, the 'enhancement' level). -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) iF4EAREIAAYFAlGKfO8ACgkQ2ugaI38ACPD7UgEAhPnkxm465nrnLrm/rbaYp7l2 Mk2OZic0KCmar9Ro82cA/RyUTF7OnnTAPON2/AregSm2Ut9VtQqex6C1qjvrjR2u =Wv/H -END PGP SIGNATURE-
Re: [gentoo-dev] Making systemd more accessible to normal users
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 08/05/13 12:06 PM, Mike Gilbert wrote: On Wed, May 8, 2013 at 11:49 AM, Ben de Groot yng...@gentoo.org wrote: On 8 May 2013 23:39, Fabio Erculiani lx...@gentoo.org wrote: On Wed, May 8, 2013 at 5:26 PM, Ben de Groot yng...@gentoo.org wrote: This sounds really wrong (tm) to me. It took me two weeks to kill that silly systemd-units pkg. All the distros around here do install systemd units with their packages and I believe that the council has already spoken about this. It sounds more wrong to me to be asking normal package maintainers to test and maintain unit files, while they don't use systemd themselves, nor have it installed. Nor would most of our users need this. I don't think we are actually asking you to test/maintain them; you can treat them as a request for permission to perform a non-maintainer commit. If users run into problems, please feel free to copy/assign us on bugs. This could work; although such a thing implies a bit of a different dynamic than i've seen occurring with anything else... So to be clear, the proposal here is that systemd team/herd would be CC'd on all systemd related bugs and handle all non-upstream systemd unit files? -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) iF4EAREIAAYFAlGKfoQACgkQ2ugaI38ACPASKgD/TjIEK3QBUjq9ONA7dX/x7xRK 1iRXVlYX9R8OTuX62twBAKgw7L5CaKX1agiPY2Zhu0jvf3x1Ag6kYy8o4wrcnHax =N6Uk -END PGP SIGNATURE-
Re: [gentoo-dev] Making systemd more accessible to normal users
Mike Gilbert schrieb: On Wed, May 8, 2013 at 12:06 PM, Chí-Thanh Christopher Nguyễn chith...@gentoo.org wrote: Fabio Erculiani schrieb: Or perhaps all these man pages, I don't need man pages locally but still most ebuilds do install them. What do we do? Users who don't want them set FEATURES=noman. Let's be serious here. I assure you that I am fully serious. Another option would be to add a dounit command to a future EAPI (like doinitd today) and make portage install them unless FEATURES=nounit (like nodoc/noinfo/noman today). Why all this mess!? Please elaborate why you think that a dounit command is a mess. A working solution right now would be to set INSTALL_MASK=/usr/lib/systemd/*. Yes, I mentioned INSTALL_MASK in a previous reply. It is however unwieldy and has the potential of unintended side effects. This is e.g. why I chose a USE=savedconfig approach for sys-kernel/linux-firmware. If you want to formalize this into a portage feature, I have no objection. Ok, done: https://bugs.gentoo.org/show_bug.cgi?id=469086 The problem with a helper function is that it would miss cases where the upstream build system actually installs the units. I think that is another issue, similar to packages directly installing init scripts or ldconfig or .desktop files. Sometimes this is ok, and sometimes maintainers prevent that. Not sure what would be the preferred way for systemd units. Best regards, Chí-Thanh Christopher Nguyễn
Re: [gentoo-dev] Making systemd more accessible to normal users
On Wed, May 8, 2013 at 11:26 AM, Ben de Groot yng...@gentoo.org wrote: In my opinion you should not be asking maintainers to add systemd units to their packages. They most likely do not have systems on which they can test these, and very few users would need them anyway. I would think it is better to add them to a separate systemd-units package. I think that makes about as much sense as putting openrc init.d scripts in a separate package. I'm contemplating migrating to systemd and when that happens I'll generally no longer be testing openrc init.d scripts in packages I maintain. That doesn't mean that I plan to drop them, or that I won't investigate bugs that get reported. As more migrate to systemd I suspect this will become a fairly common issue. Maintainers who don't use systemd need to deal with unit files in the same way that maintainers who don't use desktop environments need to deal with .desktop entries. There is no requirement that packages include these, but they're valid bugs when others submit them and maintainers are encouraged to include them. You can always ask somebody else to test them for you, and nobody is going to give you a hard time as the only people impacted by a broken unit file are systemd users who would not be better off if the unit file wasn't included. Sure, OpenRC is the default, but developers aren't required to include init.d scripts any more than they're required to include systemd units. If 70% of the developers eventually migrate and you want to hold onto OpenRC do you really want them to ignore your requests to include init.d scripts where they make sense? Rich
Re: [gentoo-dev] Making systemd more accessible to normal users
On 8 May 2013 21:51, Ben de Groot yng...@gentoo.org wrote: [...] Where upstreams ship systemd units, I don't think there is any issue. The problem is you are asking Gentoo maintainers to add unit files that upstream is not shipping. In this case we should test and maintain these ourselves, which is an additional burden for very little (if any) gain. The burden is not on the package maintainers, but on the systemd team. The perception of gain is entirely yours (and clearly biased). Mostly the complaints against adding systemd units are that it would unnecessarily clutter non-systemd installs. Users who complain are told to set INSTALL_MASK but that is somewhat unwieldy. Cluttering a system by just installing 4kb files? The council has spoken. If you don't like the decision, I am sorry. I can say the same for init scripts, they are freaking cluttering my system and they're all over. Or perhaps all these man pages, I don't need man pages locally but still most ebuilds do install them. What do we do? Let's be serious here. You are forgetting that OpenRC is, and will remain for the foreseeable future, the default on Gentoo. Any systemd related files are completely useless for most of our users. And those of us who consider systemd a cancer do not want to see such files installed at all. The overhead of the files' presence is trivial, and most users won't care. Those who do care have a trivial line to add in make.conf, and that is for the small number of people who share your vitriol for the systemd project. Gentoo is about choice and configurability. This means we will accommodate both sides: so those who want to use an alternative init system can do so, and those who want to avoid it can also keep doing so. This is a strawman. What Fabio is doing provides more choice, so fits your Gentoo is about choice criterion. Making the people who wish to provide this choice jump through hoops merely for personal dislike of the project on the other hand violates this tenet that we all seem to be so fond of. -- Arun
Re: [gentoo-dev] Making systemd more accessible to normal users
On 05/08/2013 01:08 PM, Michał Górny wrote: On Wed, 8 May 2013 23:26:57 +0800 Ben de Groot yng...@gentoo.org wrote: On 1 May 2013 18:04, Fabio Erculiani lx...@gentoo.org wrote: It looks like there is some consensus on the effort of making systemd more accessible, while there are problems with submitting bugs about new systemd units of the sort that maintainers just_dont_answer(tm). In this case, I am just giving 3 weeks grace period for maintainers to answer and then I usually go ahead adding units (I'm in systemd@ after all). In my opinion you should not be asking maintainers to add systemd units to their packages. They most likely do not have systems on which they can test these, and very few users would need them anyway. I would think it is better to add them to a separate systemd-units package. How would that package handle unit files differing per package versions? For example, changed options, relocated executables... It would effectively need to be bumped every time any package added, removed or changed a unit file requirement. Also every time a unit file-bearing package is added or removed from tree. That would be one insanely hot package. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Making systemd more accessible to normal users
On Wed, 08 May 2013 13:18:57 -0400 Michael Mol mike...@gmail.com wrote: On 05/08/2013 01:08 PM, Michał Górny wrote: On Wed, 8 May 2013 23:26:57 +0800 Ben de Groot yng...@gentoo.org wrote: On 1 May 2013 18:04, Fabio Erculiani lx...@gentoo.org wrote: It looks like there is some consensus on the effort of making systemd more accessible, while there are problems with submitting bugs about new systemd units of the sort that maintainers just_dont_answer(tm). In this case, I am just giving 3 weeks grace period for maintainers to answer and then I usually go ahead adding units (I'm in systemd@ after all). In my opinion you should not be asking maintainers to add systemd units to their packages. They most likely do not have systems on which they can test these, and very few users would need them anyway. I would think it is better to add them to a separate systemd-units package. How would that package handle unit files differing per package versions? For example, changed options, relocated executables... It would effectively need to be bumped every time any package added, removed or changed a unit file requirement. Also every time a unit file-bearing package is added or removed from tree. That would be one insanely hot package. Please note that stable unstable versions of packages may require different units. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] Making systemd more accessible to normal users
On Wed, May 8, 2013 at 1:18 PM, Michael Mol mike...@gmail.com wrote: It would effectively need to be bumped every time any package added, removed or changed a unit file requirement. Also every time a unit file-bearing package is added or removed from tree. That would be one insanely hot package. Splitting out unit files might have made sense when systemd was a highly experimental piece of software that a few people are tinkering with. It is rapidly becoming the most commonly used init.d-like implementation out there (mainly by virtue of the fact that every other one tends to be used by a single distro). Quite a few are using it on Gentoo. I think it really needs to be accommodated in the same way as openrc init.d scripts. I'm not saying that maintainers should be required to create them if they're missing (they don't even have to do that for openrc init.d scripts). However, if users or other devs contribute them and vouch that they work, then they should be included in packages. This really isn't any difference from the myriad of unusual configurations that Gentoo supports. If somebody on the Prefix team suggests some changes to my ebuild to make it more Prefix-friendly I collaborate with them. I don't need to get Prefix working on a sparc to accept their input that some change to the ebuild makes life easier on this arch. Sure, I'll make sure we're not adding regressions, but this is a community effort. The same is true if I get a bug that some package I maintain has some problem on hardware I don't own (like a different graphics card). I can't test it, but I can work with what I'm given and call for testing and so on. Bottom line is that none of this should really be inconveniencing maintainers much - nobody is required to create unit files. However, if a friendly user submits a bug with one attached, then the maintainer should strongly consider adding them to the package at the next convenient time. Nobody has to use systemd if they don't want to, but honestly, it seems like it is slowly taking over. It sounds like OpenRC will support compatible unit files, and that is really a win-win all around as it means that users of both platforms will benefit from work invested on the other. That will mean that those who want to stick with OpenRC/Eudev/whatever will have a good experience even if many devs abandon those platforms, and vice-versa. Rich
Re: [gentoo-dev] Making systemd more accessible to normal users
On Wed, May 08, 2013 at 11:49:18PM +0800, Ben de Groot wrote: On 8 May 2013 23:39, Fabio Erculiani lx...@gentoo.org wrote: On Wed, May 8, 2013 at 5:26 PM, Ben de Groot yng...@gentoo.org wrote: On 1 May 2013 18:04, Fabio Erculiani lx...@gentoo.org wrote: It looks like there is some consensus on the effort of making systemd more accessible, while there are problems with submitting bugs about new systemd units of the sort that maintainers just_dont_answer(tm). In this case, I am just giving 3 weeks grace period for maintainers to answer and then I usually go ahead adding units (I'm in systemd@ after all). In my opinion you should not be asking maintainers to add systemd units to their packages. They most likely do not have systems on which they can test these, and very few users would need them anyway. I would think it is better to add them to a separate systemd-units package. This sounds really wrong (tm) to me. It took me two weeks to kill that silly systemd-units pkg. All the distros around here do install systemd units with their packages and I believe that the council has already spoken about this. It sounds more wrong to me to be asking normal package maintainers to test and maintain unit files, while they don't use systemd themselves, nor have it installed. Nor would most of our users need this. And I believe the council has only spoken out against using a useflag for installing such files. Afaik they haven't spoken out against a systemd-units package. Please refer me to their decision if I'm wrong. I'm going to have to agree with Fabio on this one. A systemd-units package is not a good idea. The eventual goal is to get the systemd units into the upstream packages. Thanks, William signature.asc Description: Digital signature
Re: [gentoo-dev] Making systemd more accessible to normal users
El mié, 08-05-2013 a las 23:49 +0800, Ben de Groot escribió: [...] It sounds more wrong to me to be asking normal package maintainers to test and maintain unit files, while they don't use systemd themselves, nor have it installed. Nor would most of our users need this. And I believe the council has only spoken out against using a useflag for installing such files. Afaik they haven't spoken out against a systemd-units package. Please refer me to their decision if I'm wrong. -- Cheers, Ben | yngwin Gentoo developer Gentoo Qt project lead, Gentoo Wiki admin And, why not allow systemd team (or systemd-units@g.o if it's created) to test and add the unit files to each affected package? If the reported bug is caused by unit file, that team could handle it
Re: [gentoo-dev] Making systemd more accessible to normal users
On Thu, May 09, 2013 at 12:21:53AM +0800, Ben de Groot wrote: On 8 May 2013 23:49, Fabio Erculiani lx...@gentoo.org wrote: On Wed, May 8, 2013 at 5:39 PM, Chí-Thanh Christopher Nguyễn chith...@gentoo.org wrote: Ben de Groot schrieb: On 1 May 2013 18:04, Fabio Erculiani lx...@gentoo.org wrote: It looks like there is some consensus on the effort of making systemd more accessible, while there are problems with submitting bugs about new systemd units of the sort that maintainers just_dont_answer(tm). In this case, I am just giving 3 weeks grace period for maintainers to answer and then I usually go ahead adding units (I'm in systemd@ after all). In my opinion you should not be asking maintainers to add systemd units to their packages. They most likely do not have systems on which they can test these, and very few users would need them anyway. I would think it is better to add them to a separate systemd-units package. Note that a similar thing is already done with the selinux policy packages. Upstreams will _DO_ ship systemd units at some point in future. It's a completely different thing. Don't compare oranges to apples. Where upstreams ship systemd units, I don't think there is any issue. The problem is you are asking Gentoo maintainers to add unit files that upstream is not shipping. In this case we should test and maintain these ourselves, which is an additional burden for very little (if any) gain. Mostly the complaints against adding systemd units are that it would unnecessarily clutter non-systemd installs. Users who complain are told to set INSTALL_MASK but that is somewhat unwieldy. Cluttering a system by just installing 4kb files? The council has spoken. If you don't like the decision, I am sorry. I can say the same for init scripts, they are freaking cluttering my system and they're all over. Or perhaps all these man pages, I don't need man pages locally but still most ebuilds do install them. What do we do? Let's be serious here. You are forgetting that OpenRC is, and will remain for the foreseeable future, the default on Gentoo. Any systemd related files are completely useless for most of our users. And those of us who consider systemd a cancer do not want to see such files installed at all. As was said above, the distro policy is that we always install configuration files. This is how we handle logrotate and xinetd among other things. I would like to see the logrotate, xinet and systemd use flags used for this, but to get that to happen we need to change the policy -- you do that by putting this on the agenda for the council. If we do this, I would rather change it across the board and not just for systemd. So, this would mean adding an openrc use flag to every ebuild that installs openrc init scripts and using it to control that as well. Gentoo is about choice and configurability. This means we will accommodate both sides: so those who want to use an alternative init system can do so, and those who want to avoid it can also keep doing so. The argument in the past has been that we aren't taking away the choice and configurability since we have INSTALL_MASK. A separate package for the unit file would solve this problem nicely. No, it will generate a gazillion of other problems. Like conflicts arising every single day, just to name one. I think you are making the problem bigger than it is. Are there really that many packages that need a unit file, but upstream doesn't ship them yet, and many that are in the process of changing that? Either way, it should be an easy fix for systemd enthusiasts. Having separate packages for systemd units that we ship would be pretty unwieldy. I can see advantages to it, but I can definitely also see disadvantages. This same thinking could apply to OpenRC init scripts as well. William signature.asc Description: Digital signature
Re: [gentoo-dev] Making systemd more accessible to normal users
On Wed, May 08, 2013 at 11:49:18PM +0800, Ben de Groot wrote And I believe the council has only spoken out against using a useflag for installing such files. Afaik they haven't spoken out against a systemd-units package. Please refer me to their decision if I'm wrong. Wouldn't the systemd USE flag be the appropriate one to key on? The description in /usr/portage/profiles/use.desc says... systemd - Enable use of systemd-specific libraries and features like socket activation or session tracking Surely, units files qualify as systemd-specific features. -- Walter Dnes waltd...@waltdnes.org I don't run desktop environments; I run useful applications
Re: [gentoo-dev] Making systemd more accessible to normal users
On Wed, 8 May 2013 21:48:36 -0400 Walter Dnes waltd...@waltdnes.org wrote: Wouldn't the systemd USE flag be the appropriate one to key on? The description in /usr/portage/profiles/use.desc says... systemd - Enable use of systemd-specific libraries and features like socket activation or session tracking Surely, units files qualify as systemd-specific features. https://bugs.gentoo.org/show_bug.cgi?id=198901 jer
Re: [gentoo-dev] Making systemd more accessible to normal users
On Wed, May 08, 2013 at 10:31:21PM +0530, Arun Raghavan wrote The overhead of the files' presence is trivial, and most users won't care. Those who do care have a trivial line to add in make.conf, and that is for the small number of people who share your vitriol for the systemd project. Then howsabout a units ebuild that installs all available units files for systemd users? The overhead of the files' presence is trivial, and most systemd users won't care. The thread title says it all... normal Gentoo users don't use systemd. -- Walter Dnes waltd...@waltdnes.org I don't run desktop environments; I run useful applications
Re: [gentoo-dev] Making systemd more accessible to normal users
On Wed, May 8, 2013 at 9:18 PM, Walter Dnes waltd...@waltdnes.org wrote: On Wed, May 08, 2013 at 10:31:21PM +0530, Arun Raghavan wrote The overhead of the files' presence is trivial, and most users won't care. Those who do care have a trivial line to add in make.conf, and that is for the small number of people who share your vitriol for the systemd project. Then howsabout a units ebuild that installs all available units files for systemd users? The overhead of the files' presence is trivial, and most systemd users won't care. The thread title says it all... normal Gentoo users don't use systemd. For now. Regards. -- Canek Peláez Valdés Posgrado en Ciencia e Ingeniería de la Computación Universidad Nacional Autónoma de México
Re: [gentoo-dev] Making systemd more accessible to normal users
On 05/04/2013 03:12 PM, Fabio Erculiani wrote: I just forgot the tricky part. If future lvm versions are going to use udev more extensively (for eg: storing more critical metadata in it), the net result will be that mdev won't work anymore. This is why I wrote that lvm is working by miracle for now. mdev is not future proof wrt lvm support. Sounds dangerously bad, I guess the response by the interested parties (e.g. nas builders) will be moving lvm in bb or switch to dragonfly or freebsd. lu
Re: [gentoo-dev] Making systemd more accessible to normal users
On 05/04/2013 03:05 PM, Fabio Erculiani wrote: Long story short, we should: 1) give up with cross compiler support in genkernel, which has been anyway in a broken state for ages. Nobody is using it anyway. 2) make possible to optionally use udev in the initramfs (compiling just for it is a pita and the trend here [dracut and others do this] is to copy udevd from the system) 3) default to udev? Uhm... sounds quite unpleasant and I'm really wondering why having udev as middle-man for storing userspace metadata. The netlink broadcast should be available to everybody for acting upon, using/extending it for such tasks isn't possible? lu
Re: [gentoo-dev] Making systemd more accessible to normal users
On 05/01/2013 12:04 PM, Fabio Erculiani wrote: PLEASE DO NOT START A FLAME WAR AND READ ON FIRST. THIS IS NOT A POST AGAINST OPENRC. Amen With the release of Sabayon 13.04 [1] and thanks to the efforts I put into the systemd-love overlay [2], systemd has become much more accessible and easy to migrate to/from openrc. Both are able to happily coexist and logind/consolekit detection is now done at runtime. It is sad to say that the territoriality in base-system (and toolchain) is not allowing any kind of progress [3] [4]. This is nothing new, by the way. There are several components that need patching in order to work as expected with systemd: - polkit needs a patch that enables runtime detection of logind/consolekit - pambase needs to drop USE=systemd and always enable the optional module pam_systemd.so - genkernel needs to migrate to *udev (or as I did, provide a --udev genkernel option), mdev is unable to properly activate LVM volumes and LVM is actually working by miracle with openrc. Alternatively, we should migrate to dracut. [unrelated] Do you have more insights about this part? mdev MUST work, lots of thin recovery options are based on busybox. - networkmanager need not to install/remove files depending on USE=systemd but rather detect systemd at runtime, which is a 3 lines script. Sounds sensible. - openrc-settingsd needs to support eselect-settingsd, which makes possible to switch the settingsd implementation at runtime, between openrc and systemd. This also removes the silly conflict between openrc-settingsd and systemd friends. Would make sense merge init and settingsd in a single eselect or at least make so switching init would warn if the settingsd doesn't match? - genkernel should at least support plymouth (work in progress my side) Looking forward to it. - other ~490 systemd units are missing at this time and writing them could also be a great GSoC project (don't look at me, I'm busy enough). Hopefully we might have a gsoc student volunteering to make a runscript/lsb-script/systemd-unit compiler and a small abstraction so we write a single init.d script and generate what's needed. Probably we might even support pure-runit that way with minimal effort. It looks like there is some consensus on the effort of making systemd more accessible, while there are problems with submitting bugs about new systemd units of the sort that maintainers just_dont_answer(tm). In this case, I am just giving 3 weeks grace period for maintainers to answer and then I usually go ahead adding units (I'm in systemd@ after all). See above. The only remaining problem is about eselect-sysvinit, for this reason, I am probably going to create a new separate pkg called _sysvinit-next_, that contains all the fun stuff many developers were not allowed to commit (besides my needs, there is also the need of splitting sysvinit due to the issues reported in [4]). I am sure that a masked alternative sysvinit ebuild won't hurt anybody and will make Gentoo a bit more fun to use. Exactly, which is the problem at hand? I'd like to be able to safely switch back and forth sysvinit and bb-init as well. The final outcome will hopefully be: - easier to migrate from/to systemd, at runtime, with NO recompilation at all (just enable USE=systemd and switch the device manager from *udev to systemd -- unless somebody wants to drop the udev part from systemd, if at all possible) - we give the users the right to choose without driving them nuts with weird emerge-fu. - we make possible to support new init systems in future, and even specific init wrappers (bootchart anyone?) Here! o/ Currently in my list are - bootchart2 (as an add-on to the other init systems) - bb-init (requires different custom inittab) - runit (openrc can use it instead thanks to benda xu past GSoC) - we prepare the path towards a painless migration from consolekit (deprecated for long time now) to logind (we probably need to fork it off the systemd pkg -- upstream projects are _dropping_ consolekit support right now!) Again it is something I consider an option for a GSoC project, we have already some openrc variant for other systemd-originated daemons in our git. - we put back some fun into Gentoo That's always good. If you want to see a working implementation of my systemd-love efforts, just go download [1] and see things working yourself. Thank you a lot for your positive attitude and the huge effort =) lu
Re: [gentoo-dev] Making systemd more accessible to normal users
On Sat, May 4, 2013 at 6:42 AM, Luca Barbato lu_z...@gentoo.org wrote: Hopefully we might have a gsoc student volunteering to make a runscript/lsb-script/systemd-unit compiler and a small abstraction so we write a single init.d script and generate what's needed. Probably we might even support pure-runit that way with minimal effort. I'm skeptical that this will ever make sense - both init systems have features that it would make sense for units/scripts to make use of in a more tailored fashion. That said, if you really wanted to inter-convert, my gut feeling is that it would be easier to go from a systemd unit to an init.d script, and not the other way around. A systemd unit is more like a specification - it describes the end result of what systemd should do. An init.d script is an executable program - it can do virtually anything even if they usually start out with a common skeleton. I guess you could run the thing in a sandbox and carefully capture what happens, and look in particular for calls to start-stop-daemon and such, but it would be tricky. The reality is that systemd units are floating around all over the place - when I installed it on a Gentoo box I ended up just Googling for already-written units for daemons that lacked them in Gentoo and tweaked them. All that really need to happen is for those who use systemd to submit them as bug attachments and maintainers should commit them. Maybe a quick guide should be tossed together suggesting the best way to install them (they're just text files in the proper directory, but perhaps an eclass exists to take care of this). Systemd units are much easier to write (typically) than init.d scripts so this could be an area where end-users could contribute. Rich
Re: [gentoo-dev] Making systemd more accessible to normal users
On Sat, May 4, 2013 at 12:42 PM, Luca Barbato lu_z...@gentoo.org wrote: On 05/01/2013 12:04 PM, Fabio Erculiani wrote: PLEASE DO NOT START A FLAME WAR AND READ ON FIRST. THIS IS NOT A POST AGAINST OPENRC. Amen With the release of Sabayon 13.04 [1] and thanks to the efforts I put into the systemd-love overlay [2], systemd has become much more accessible and easy to migrate to/from openrc. Both are able to happily coexist and logind/consolekit detection is now done at runtime. It is sad to say that the territoriality in base-system (and toolchain) is not allowing any kind of progress [3] [4]. This is nothing new, by the way. There are several components that need patching in order to work as expected with systemd: - polkit needs a patch that enables runtime detection of logind/consolekit - pambase needs to drop USE=systemd and always enable the optional module pam_systemd.so - genkernel needs to migrate to *udev (or as I did, provide a --udev genkernel option), mdev is unable to properly activate LVM volumes and LVM is actually working by miracle with openrc. Alternatively, we should migrate to dracut. [unrelated] Do you have more insights about this part? mdev MUST work, lots of thin recovery options are based on busybox. Scenario: - you have an initramfs with mdev, your pivot_chroot system runs udev. - you have a LVM volume group, containing the lvm volume for / and /home, and perhaps you also have swap on another volume. - you boot using the current genkernel initramfs, which uses mdev and comes with lvm support The initramfs code activates your lvm volumes, lvm itself may or not may be compiled with udev support. In the former case, nothing gets written onto /run/udev (and devtmpfs), in the latter case, lvm writes metadata that are useful to lvm itself to udev. mdev is not udev, doesn't deal with udev rules so the metadata is either pristine or completely unavailable. busybox switches root and the boot starts: you obviously have lvm compiled with udev there, since you're using udev (or systemd-udevd, or gudev). The lvm there is either unable to find valid metadata so it doesn't automatically activate the volumes (note: /home does not get activated by the initramfs code) or, until some time ago but now defaulted to off, lvm itself creates the device nodes (which should have been created by udev + udev rules if lvm is compiled with udev support). If it's not enough, our current genkernel initramfs code (I fixed this as well, it's in the systemd-love overlay) doesn't mount --move /run to /newroot before switching root, so /run/udev is not ported over, which means that even if mdev would have been able to do do all the udev magic, things wouldn't work anyway. Long story short, we should: 1) give up with cross compiler support in genkernel, which has been anyway in a broken state for ages. Nobody is using it anyway. 2) make possible to optionally use udev in the initramfs (compiling just for it is a pita and the trend here [dracut and others do this] is to copy udevd from the system) 3) default to udev? - networkmanager need not to install/remove files depending on USE=systemd but rather detect systemd at runtime, which is a 3 lines script. Sounds sensible. Also, I forgot that I wrote a NetworkManager patch that makes it able to detect logind/consolekit at runtime. It works and is in the systemd-love overlay (it's a git format-patch patch). - openrc-settingsd needs to support eselect-settingsd, which makes possible to switch the settingsd implementation at runtime, between openrc and systemd. This also removes the silly conflict between openrc-settingsd and systemd friends. Would make sense merge init and settingsd in a single eselect or at least make so switching init would warn if the settingsd doesn't match? They are really two separate things, even though I agree that it should be made even easier. I don't think it's hard though. - genkernel should at least support plymouth (work in progress my side) Looking forward to it. I should have something ready soon. - other ~490 systemd units are missing at this time and writing them could also be a great GSoC project (don't look at me, I'm busy enough). Hopefully we might have a gsoc student volunteering to make a runscript/lsb-script/systemd-unit compiler and a small abstraction so we write a single init.d script and generate what's needed. Probably we might even support pure-runit that way with minimal effort. It looks like there is some consensus on the effort of making systemd more accessible, while there are problems with submitting bugs about new systemd units of the sort that maintainers just_dont_answer(tm). In this case, I am just giving 3 weeks grace period for maintainers to answer and then I usually go ahead adding units (I'm in systemd@ after all). See above. The only remaining problem is about eselect-sysvinit, for this reason, I am probably going to create a new separate
Re: [gentoo-dev] Making systemd more accessible to normal users
On Sat, May 4, 2013 at 3:05 PM, Fabio Erculiani lx...@gentoo.org wrote: Scenario: - you have an initramfs with mdev, your pivot_chroot system runs udev. - you have a LVM volume group, containing the lvm volume for / and /home, and perhaps you also have swap on another volume. - you boot using the current genkernel initramfs, which uses mdev and comes with lvm support The initramfs code activates your lvm volumes, lvm itself may or not may be compiled with udev support. In the former case, nothing gets written onto /run/udev (and devtmpfs), in the latter case, lvm writes metadata that are useful to lvm itself to udev. mdev is not udev, doesn't deal with udev rules so the metadata is either pristine or completely unavailable. busybox switches root and the boot starts: you obviously have lvm compiled with udev there, since you're using udev (or systemd-udevd, or gudev). The lvm there is either unable to find valid metadata so it doesn't automatically activate the volumes (note: /home does not get activated by the initramfs code) or, until some time ago but now defaulted to off, lvm itself creates the device nodes (which should have been created by udev + udev rules if lvm is compiled with udev support). If it's not enough, our current genkernel initramfs code (I fixed this as well, it's in the systemd-love overlay) doesn't mount --move /run to /newroot before switching root, so /run/udev is not ported over, which means that even if mdev would have been able to do do all the udev magic, things wouldn't work anyway. Long story short, we should: 1) give up with cross compiler support in genkernel, which has been anyway in a broken state for ages. Nobody is using it anyway. 2) make possible to optionally use udev in the initramfs (compiling just for it is a pita and the trend here [dracut and others do this] is to copy udevd from the system) 3) default to udev? I just forgot the tricky part. If future lvm versions are going to use udev more extensively (for eg: storing more critical metadata in it), the net result will be that mdev won't work anymore. This is why I wrote that lvm is working by miracle for now. mdev is not future proof wrt lvm support. -- Fabio Erculiani -- Fabio Erculiani
Re: [gentoo-dev] Making systemd more accessible to normal users
El sáb, 04-05-2013 a las 15:05 +0200, Fabio Erculiani escribió: [...] - networkmanager need not to install/remove files depending on USE=systemd but rather detect systemd at runtime, which is a 3 lines script. Sounds sensible. Also, I forgot that I wrote a NetworkManager patch that makes it able to detect logind/consolekit at runtime. It works and is in the systemd-love overlay (it's a git format-patch patch). If you even has fixes... I would simply report a bug to bugs.gentoo.org :/
Re: [gentoo-dev] Making systemd more accessible to normal users
On Thu, May 02, 2013 at 04:26:06PM +1200, Kent Fredric wrote: - its a consistent approach that is bootloader agnostic - it doesn't require you to understand your bootloaders scripting system to add it to the init= line - its no brains required, and hard to mess up Why should we do something boot loader agnostic for the init system when editing config files is something that all gentoo users/sysadmins are expected to understand? bootloader configuration under grub1 for instance, was quite straight-forward. Now with grub-2, its quite convoluted, for me at least. I haven't looked at grub2 yet, but I can't imagine it being convoluted based on the documentation I have read. Its also sometimes a bit confusing if you need something other than /sbin/init as your init, because sometimes you need some pre-init stuff ( like genkernel does ), and you need some /other/ parameter other than init= so that the pre-init still runs and then passes over to init Now you are talking about an initramfs, and no symlink is going to take care of that. You also still have to keep your boot loader configuration up to date whenyou upgrade your kernel. Having a symlink that will just do the right thing is helpful for these cases. I don't see how the symlink is going to help anything since it doesn't preclude you editing your boot loader configuration. Against, the symlink may introduce parts that are breakable, like if user messes up and places the destination of the symlink on a different partition ( shouldn't be a problem, but might be ), or if you're doing an initird that has init baked into it, you'd have to regenerate that initrd after changing the symlink ( I think, maybe not, its probably not even a problem, its just something I'd have to check ) And also, if for whatever reason systemd becomes unbootable it might be slightly hard to boot with the right init if you can't change kernel parameters during boot time. But noted, those last 2 against reasons are edge cases, where the arguments for it are majority cases, so collectively I'm still in favour of the eselect + symlinks approach. If this does ever hit the tree, I think it should be defaulted to off and users should be able to turn it on if they want. William signature.asc Description: Digital signature
Re: [gentoo-dev] Making systemd more accessible to normal users
On Thu, May 2, 2013 at 2:05 PM, William Hubbs willi...@gentoo.org wrote: On Thu, May 02, 2013 at 04:26:06PM +1200, Kent Fredric wrote: bootloader configuration under grub1 for instance, was quite straight-forward. Now with grub-2, its quite convoluted, for me at least. I haven't looked at grub2 yet, but I can't imagine it being convoluted based on the documentation I have read. If you manually write your own configuration for GRUB2, it is no more convoluted than for GRUB Legacy. If you use grub-mkconfig to generate a configuration file, you can append the init option by setting GRUB_CMDLINE_LINUX=init=/usr/lib/systemd/systemd in /etc/default/grub. Either way, it's pretty simple.
Re: [gentoo-dev] Making systemd more accessible to normal users
On Thu, May 2, 2013 at 8:13 PM, Mike Gilbert flop...@gentoo.org wrote: If you manually write your own configuration for GRUB2, it is no more convoluted than for GRUB Legacy. If you use grub-mkconfig to generate a configuration file, you can append the init option by setting GRUB_CMDLINE_LINUX=init=/usr/lib/systemd/systemd in /etc/default/grub. Not all the Gentoo users are as skilled as you (a developer). Having a programmatic, bootloader agnostic way to swap /sbin/init is useful for the reasons I explained. Yet I haven't read any solid reason not to do that. Either way, it's pretty simple. If it's that simple, why on earth do we have all the eselect modules we have!? Extra modules: audicle Manage /usr/bin/audicle audio engine bashcomp Manage contributed bash-completion scripts binutils Manage installed versions of sys-devel/binutils blas Manage installed BLAS implementations bzimage Switch bzImage default kernel by updating /boot/bzImage symlink cblas Manage installed CBLAS implementations cdparanoiaManage /usr/bin/cdparanoia implementation chuck Manage /usr/bin/chuck audio engine ctags Manage /usr/bin/ctags implementations ecj Manage ECJ targets editorManage the EDITOR environment variable emacs Manage /usr/bin/emacs version env Manage environment variables set in /etc/env.d/ esd Select esound daemon or wrapper etags Manage /usr/bin/etags implementations fontconfigManage fontconfig /etc/fonts/conf.d/ symlinks gnat Manage the installed gnat compilers gnome-shell-extensionsManage default settings for systemwide GNOME Shell extensions infinalityManage the /etc/fonts/infinality/conf.d symlink java-nsplugin Manage the Java plugin for Netscape-like Browsers java-vm Manage the Java system and user VM kernelManage the /usr/src/linux symlink lapackManage installed LAPACK implementations lcdfilter Manage the /etc/env.d/99lcdfilter symlink lightdm Switch between LightDM greeters localeManage the LANG environment variable maven Manage Maven targets mesa Manage the OpenGL driver architecture used by media-libs/mesa miniaudicle Manage /usr/bin/miniAudicle audio engine modules Query eselect modules mpg123Manage /usr/bin/mpg123 implementation mpost Manage /usr/bin/mpost implementations news Read Gentoo (GLEP 42) news items notify-send Manage /usr/bin/notify-send implementation nxserver Manages the configuration of NX servers oodictManage the configuration of dictionaries for OpenOffice.Org. openclManage the OpenCL implementation used by your system openglManage the OpenGL implementation used by your system package-manager Manage the PACKAGE_MANAGER environment variable pager Manage the PAGER environment variable pdftexManage /usr/bin/pdftex implementations php Manage php installations pinentry Manage /usr/bin/pinentry implementation postgresqlManage active PostgreSQL client applications and libraries profile Manage the make.profile symlink pythonManage Python symlinks qtgraphicssystem Manage the system-wide active Qt Graphics System rails Manage Ruby on Rails versions rcManage /etc/init.d scripts in runlevels ruby Manage Ruby symlinks settingsd Switch between settingsd implementations shManage /bin/sh (POSIX shell) implementations sndpeek Manage /usr/bin/sndpeek audio engine sysvinit Switch between sysvinit implementations timidity Select default system patchset for TiMidity++ unisonManage /usr/bin/unison versions vdr-pluginManage VDR plugins viManage /usr/bin/vi implementations visualManage the VISUAL environment variable wxwidgets Manage the system default wxWidgets profile. xvmc Manage the XvMC implementation used by your system Why aren't we telling people to just edit config files!? -- Fabio Erculiani
Re: [gentoo-dev] Making systemd more accessible to normal users
Fabio Erculiani schrieb: Not all the Gentoo users are as skilled as you (a developer). Having a programmatic, bootloader agnostic way to swap /sbin/init is useful for the reasons I explained. Yet I haven't read any solid reason not to do that. Another bootloader agnostic way is to pass init=.. via CONFIG_CMDLINE. Not carrying more deviations from upstream than necessary is a worthwhile goal for any sane distro. Especially when it has not even been attempted to get this change merged upstream. Either way, it's pretty simple. If it's that simple, why on earth do we have all the eselect modules we have!? [...] Why aren't we telling people to just edit config files!? I don't see your point? Besides eselect modules which manage symlinks when users could instead edit configuration files, there exist eselect modules which modify config files for the user, or those where symlinks are managed without an equivalent editing of configuration files, or where symlinks are managed in an upstream approved way. Best regards, Chí-Thanh Christopher Nguyễn
Re: [gentoo-dev] Making systemd more accessible to normal users
On Thu, May 2, 2013 at 3:01 PM, Fabio Erculiani lx...@gentoo.org wrote: Not all the Gentoo users are as skilled as you (a developer). Having a programmatic, bootloader agnostic way to swap /sbin/init is useful for the reasons I explained. Yet I haven't read any solid reason not to do that. Well, there is no reason that an eselect module couldn't edit the boot configuration, but not with the current way that everybody generates them manually anyway. Keep in mind that any Gentoo user who can't edit a boot loader configuration is limited to booting from LiveCDs. The bootloader is installed and configured manually in Gentoo, following the handbook. Running openrc and systemd in parallel under grub legacy (the config anybody without more exotic requirements and knowledge uses) is just a matter of duplicating a few lines of the config file, renaming the menu item name, and setting init= on one of them. Now you can boot into either from the boot menu. As I mentioned before on this list I'm all for having some packages that actually install a working default kernel, initramfs, boot config, etc. They might even be part of a profile, so that if a user eselects that profile at install-time and does an emerge -uDN world they can then just type reboot when it finishes and get a working system. However, none of that exists now. If it did exist, then manipulating those standardized files via eselect would be quite possible as well (most likely the boot config would be built from some kind of conf.d directory with a script that updates it when needed, and eselect and other packages coudl dump stuff in that conf.d directory as needed just as we do with env.d and so on). I should probably take a few minutes to learn how all this was implemented in Sabayon as it is likely a solved problem. Of course, the handbook would just list this as another option and gentoo-sources and such would never go away. Rich
Re: [gentoo-dev] Making systemd more accessible to normal users
On Thu, May 2, 2013 at 3:01 PM, Fabio Erculiani lx...@gentoo.org wrote: On Thu, May 2, 2013 at 8:13 PM, Mike Gilbert flop...@gentoo.org wrote: If you manually write your own configuration for GRUB2, it is no more convoluted than for GRUB Legacy. If you use grub-mkconfig to generate a configuration file, you can append the init option by setting GRUB_CMDLINE_LINUX=init=/usr/lib/systemd/systemd in /etc/default/grub. Not all the Gentoo users are as skilled as you (a developer). Having a programmatic, bootloader agnostic way to swap /sbin/init is useful for the reasons I explained. Yet I haven't read any solid reason not to do that. I was just providing some technical insight as the maintainer of that package; I didn't mean to set off another tangent, but oh well. Editing a configuration file does not require some great level of skill. I think you give our users too little credit. Give them good/simple documentation, and they can run with it. I am not strongly opposed your eselect module for init; I just think it is unnecessary. Adjusting a bootloader config is not the mystical impossibility that you seem to make it out to be. If it were, we would have automated it along with kernel building and initramfs generation. Either way, it's pretty simple. If it's that simple, why on earth do we have all the eselect modules we have!? Why aren't we telling people to just edit config files!? I guess people like writing eselect modules for no good reason? ;-) Note that many of them do more than simply edit a configuration file. Many do quite a bit of symlink manipulation, which is a good application of eselect IMO.
Re: [gentoo-dev] Making systemd more accessible to normal users
On Thu, May 02, 2013 at 03:39:25PM -0400, Mike Gilbert wrote: On Thu, May 2, 2013 at 3:01 PM, Fabio Erculiani lx...@gentoo.org wrote: On Thu, May 2, 2013 at 8:13 PM, Mike Gilbert flop...@gentoo.org wrote: If you manually write your own configuration for GRUB2, it is no more convoluted than for GRUB Legacy. If you use grub-mkconfig to generate a configuration file, you can append the init option by setting GRUB_CMDLINE_LINUX=init=/usr/lib/systemd/systemd in /etc/default/grub. Not all the Gentoo users are as skilled as you (a developer). Having a programmatic, bootloader agnostic way to swap /sbin/init is useful for the reasons I explained. Yet I haven't read any solid reason not to do that. I was just providing some technical insight as the maintainer of that package; I didn't mean to set off another tangent, but oh well. Editing a configuration file does not require some great level of skill. I think you give our users too little credit. Give them good/simple documentation, and they can run with it. Agreed. All of our users who have installed Gentoo by following the handbook know how to edit configuration files since there are several they are required to edit as part of the installation process. You have to do some work to maintain a Gentoo system. We are not and do not claim to be a distro where everything just works out of the box. I am not strongly opposed your eselect module for init; I just think it is unnecessary. Adjusting a bootloader config is not the mystical impossibility that you seem to make it out to be. If it were, we would have automated it along with kernel building and initramfs generation. Right. I think it is completely unnecessary given what we consider the basic knowledge level of our users. It causes more work for the developers with no gain for users. William signature.asc Description: Digital signature
Re: [gentoo-dev] Making systemd more accessible to normal users
On 3 May 2013 07:01, Fabio Erculiani lx...@gentoo.org wrote: If it's that simple, why on earth do we have all the eselect modules we have!? Hm, upon reading that list and seeing what they do, it raises another argument in favour of eselect: If there needs to be more things changed prior to reboot than simply changing which init is invoked, having an eselect module gives a good place to put relevant related changes to make it work. It also gives a good place to do sanity checks on your system so it knows that the change of init invocation will actually work on your machine. -- Kent
Re: [gentoo-dev] Making systemd more accessible to normal users
On Fri, May 03, 2013 at 08:27:36AM +1200, Kent Fredric wrote: On 3 May 2013 07:01, Fabio Erculiani lx...@gentoo.org wrote: If it's that simple, why on earth do we have all the eselect modules we have!? Hm, upon reading that list and seeing what they do, it raises another argument in favour of eselect: If there needs to be more things changed prior to reboot than simply changing which init is invoked, having an eselect module gives a good place to put relevant related changes to make it work. There are no other changes in this case though; that's the point of this discussion. You just emerge systemd and switch init= to the appropriate path in your boot loader configuration, , or better yet, add a separate entry to your boot loader configuration that boots you up with systemd so that you can recover if things do not work. If you use this symlink approach to actually switch your init to point to systemd, then you boot and things don't work, you are hosed. William signature.asc Description: Digital signature
Re: [gentoo-dev] Making systemd more accessible to normal users
William Hubbs schrieb: If you use this symlink approach to actually switch your init to point to systemd, then you boot and things don't work, you are hosed. Well, not fully hosed. You could still edit your kernel command line from the boot loader pointing init=.. to the actual location and not the symlink (or have a backup entry ready, but then any gains from switching symlinks are negated). Best regards, Chí-Thanh Christopher Nguyễn
Re: [gentoo-dev] Making systemd more accessible to normal users
El mié, 01-05-2013 a las 12:04 +0200, Fabio Erculiani escribió: [...] - other ~490 systemd units are missing at this time and writing them could also be a great GSoC project (don't look at me, I'm busy enough). [...] Can't them be stolen from other distros running systemd? [...] The only remaining problem is about eselect-sysvinit, for this reason, I am probably going to create a new separate pkg called _sysvinit-next_, that contains all the fun stuff many developers were not allowed to commit (besides my needs, there is also the need of splitting sysvinit due to the issues reported in [4]). I am sure that a masked alternative sysvinit ebuild won't hurt anybody and will make Gentoo a bit more fun to use. I am unable to find exact advantage of changing init system without rebooting :/, what is the advantage of booting with an init.d and shutting down with a different one? The final outcome will hopefully be: - easier to migrate from/to systemd, at runtime, with NO recompilation at all (just enable USE=systemd and switch the device manager from *udev to systemd -- unless somebody wants to drop the udev part from systemd, if at all possible) Are udev and systemd-udev-part really equivalent? I mean, since they are maintained by different people downstream, I am not sure if there would be differences in how udev from udev ebuild and udev from systemd ebuild will behave. Best regards and thanks for your work!
Re: [gentoo-dev] Making systemd more accessible to normal users
On Wed, May 1, 2013 at 12:50 PM, Pacho Ramos pa...@gentoo.org wrote: El mié, 01-05-2013 a las 12:04 +0200, Fabio Erculiani escribió: [...] - other ~490 systemd units are missing at this time and writing them could also be a great GSoC project (don't look at me, I'm busy enough). [...] Can't them be stolen from other distros running systemd? Sure, Arch and Fedora repositories are a good source. [...] The only remaining problem is about eselect-sysvinit, for this reason, I am probably going to create a new separate pkg called _sysvinit-next_, that contains all the fun stuff many developers were not allowed to commit (besides my needs, there is also the need of splitting sysvinit due to the issues reported in [4]). I am sure that a masked alternative sysvinit ebuild won't hurt anybody and will make Gentoo a bit more fun to use. I am unable to find exact advantage of changing init system without rebooting :/, what is the advantage of booting with an init.d and shutting down with a different one? No, you don't boot with A and shutdown with B. B is loaded by the kernel at the next boot. Switching init system is the only way to roll out a migration path, among other things I already wrote about on the eselect-sysvinit bug. The final outcome will hopefully be: - easier to migrate from/to systemd, at runtime, with NO recompilation at all (just enable USE=systemd and switch the device manager from *udev to systemd -- unless somebody wants to drop the udev part from systemd, if at all possible) Are udev and systemd-udev-part really equivalent? I mean, since they are maintained by different people downstream, I am not sure if there would be differences in how udev from udev ebuild and udev from systemd ebuild will behave. This needs investigation. Best regards and thanks for your work! -- Fabio Erculiani
Re: [gentoo-dev] Making systemd more accessible to normal users
El mié, 01-05-2013 a las 13:00 +0200, Fabio Erculiani escribió: [...] The only remaining problem is about eselect-sysvinit, for this reason, I am probably going to create a new separate pkg called _sysvinit-next_, that contains all the fun stuff many developers were not allowed to commit (besides my needs, there is also the need of splitting sysvinit due to the issues reported in [4]). I am sure that a masked alternative sysvinit ebuild won't hurt anybody and will make Gentoo a bit more fun to use. I am unable to find exact advantage of changing init system without rebooting :/, what is the advantage of booting with an init.d and shutting down with a different one? No, you don't boot with A and shutdown with B. B is loaded by the kernel at the next boot. Switching init system is the only way to roll out a migration path, among other things I already wrote about on the eselect-sysvinit bug. Ah! OK, I misunderstood the runtime sense, in that case looks interesting :D
Re: [gentoo-dev] Making systemd more accessible to normal users
On 05/01/13 05:04, Fabio Erculiani wrote: PLEASE DO NOT START A FLAME WAR AND READ ON FIRST. THIS IS NOT A POST AGAINST OPENRC. With the release of Sabayon 13.04 [1] and thanks to the efforts I put into the systemd-love overlay [2], systemd has become much more accessible and easy to migrate to/from openrc. Both are able to happily coexist and logind/consolekit detection is now done at runtime. It is sad to say that the territoriality in base-system (and toolchain) is not allowing any kind of progress [3] [4]. This is nothing new, by the way. There are several components that need patching in order to work as expected with systemd: - polkit needs a patch that enables runtime detection of logind/consolekit - pambase needs to drop USE=systemd and always enable the optional module pam_systemd.so - genkernel needs to migrate to *udev (or as I did, provide a --udev genkernel option), mdev is unable to properly activate LVM volumes and LVM is actually working by miracle with openrc. Alternatively, we should migrate to dracut. - networkmanager need not to install/remove files depending on USE=systemd but rather detect systemd at runtime, which is a 3 lines script. - openrc-settingsd needs to support eselect-settingsd, which makes possible to switch the settingsd implementation at runtime, between openrc and systemd. This also removes the silly conflict between openrc-settingsd and systemd friends. - genkernel should at least support plymouth (work in progress my side) - other ~490 systemd units are missing at this time and writing them could also be a great GSoC project (don't look at me, I'm busy enough). All this would come with no cost for the current openrc state (actually, my initramfs speed improvements patches in genkernel.git also benefit openrc). If Gentoo is about choice, we should give our users the right to choose between the init system they like the most. It looks like there is some consensus on the effort of making systemd more accessible, while there are problems with submitting bugs about new systemd units of the sort that maintainers just_dont_answer(tm). In this case, I am just giving 3 weeks grace period for maintainers to answer and then I usually go ahead adding units (I'm in systemd@ after all). The only remaining problem is about eselect-sysvinit, for this reason, I am probably going to create a new separate pkg called _sysvinit-next_, that contains all the fun stuff many developers were not allowed to commit (besides my needs, there is also the need of splitting sysvinit due to the issues reported in [4]). I am sure that a masked alternative sysvinit ebuild won't hurt anybody and will make Gentoo a bit more fun to use. The final outcome will hopefully be: - easier to migrate from/to systemd, at runtime, with NO recompilation at all (just enable USE=systemd and switch the device manager from *udev to systemd -- unless somebody wants to drop the udev part from systemd, if at all possible) - we give the users the right to choose without driving them nuts with weird emerge-fu. - we make possible to support new init systems in future, and even specific init wrappers (bootchart anyone?) - we prepare the path towards a painless migration from consolekit (deprecated for long time now) to logind (we probably need to fork it off the systemd pkg -- upstream projects are _dropping_ consolekit support right now!) - we put back some fun into Gentoo If you want to see a working implementation of my systemd-love efforts, just go download [1] and see things working yourself. [1] http://www.sabayon.org/release/press-release-sabayon-1304 [2] https://github.com/Sabayon/systemd-love [3] For instance: https://bugs.gentoo.org/show_bug.cgi?id=465236 [4] useless crap: https://bugs.gentoo.org/show_bug.cgi?id=399615 Cheers, Isn't there a tracker (and if not, why have you not created one yet :P ) -- -- Matthew Thode (prometheanfire) signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Making systemd more accessible to normal users
There is no tracker yet. But it may be very well materialize at some point. -- Fabio Erculiani
Re: [gentoo-dev] Making systemd more accessible to normal users
On Wed, May 1, 2013 at 6:04 AM, Fabio Erculiani lx...@gentoo.org wrote: - genkernel needs to migrate to *udev (or as I did, provide a --udev genkernel option), mdev is unable to properly activate LVM volumes and LVM is actually working by miracle with openrc. Alternatively, we should migrate to dracut. I'm not sure what migrating to dracut actually means. A gentoo install doesn't include genkernel in the first place - it is installed manually. If you mean documenting how to use dracut in the handbook, then I think that makes sense - we already document multiple alternatives like genkernel, manual kernel builds, grub, lilo, etc. I've been running dracut for almost a year now and it has been working well, though I might note that I had to build a custom module to get mdadm+LVM to work (not sure if current versions work out of the box, and my use of old mdadm metadata versions due to previously having followed the Gentoo mdadm+lvm guide might have something to do with it). Honestly, I'm not sure how important it is to be able to switch back/forth at runtime. We should definitely support both options reasonably well, but not to the point where people end up with a lot of dependencies/complexity that a typical user doesn't actually have need for. Rich
Re: [gentoo-dev] Making systemd more accessible to normal users
On 5/1/13 3:04 AM, Fabio Erculiani wrote: It is sad to say that the territoriality in base-system (and toolchain) is not allowing any kind of progress [3] [4]. This is nothing new, by the way. [4] useless crap: https://bugs.gentoo.org/show_bug.cgi?id=399615 As far as I read the bug, Mike (vapier) is doing the right thing. Distros doing lots of custom changes can only add more chaos to the picture. Have you reached out to relevant upstreams? If they refuse to make changes, that's a different story. So far I think it's reasonable to go to upstreams first. Paweł signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Making systemd more accessible to normal users
On Wed, 01 May 2013 12:52:09 -0700 Paweł Hajdan, Jr. phajdan...@gentoo.org wrote: On 5/1/13 3:04 AM, Fabio Erculiani wrote: It is sad to say that the territoriality in base-system (and toolchain) is not allowing any kind of progress [3] [4]. This is nothing new, by the way. [4] useless crap: https://bugs.gentoo.org/show_bug.cgi?id=399615 As far as I read the bug, Mike (vapier) is doing the right thing. Distros doing lots of custom changes can only add more chaos to the picture. Have you reached out to relevant upstreams? If they refuse to make changes, that's a different story. So far I think it's reasonable to go to upstreams first. Well, the first thing to do would be making /sbin/init a symlink and renaming sysvinit. Now, why would sysvinit upstream do such a thing? I doubt it's a change that upstream should be willing to do because of what downstream wants to do afterwards... -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] Making systemd more accessible to normal users
On Wed, May 1, 2013 at 9:52 PM, Paweł Hajdan, Jr. phajdan...@gentoo.org wrote: On 5/1/13 3:04 AM, Fabio Erculiani wrote: As far as I read the bug, Mike (vapier) is doing the right thing. Distros doing lots of custom changes can only add more chaos to the picture. We are a distribution, we have our own goals, thus we change the code to better integrate with our ecosystem. That's part of the game. If we don't want to do that, we shouldn't be running a distro in the first place. Have you reached out to relevant upstreams? If they refuse to make changes, that's a different story. So far I think it's reasonable to go to upstreams first. For just a symlink swap and some file moves? (re: sysvinit) We don't need to bless upstream first for such small changes. Paweł -- Fabio Erculiani
Re: [gentoo-dev] Making systemd more accessible to normal users
Fabio, I think you're doing awesome work! Steven, I think you can behave a lot better on the internet. kthx. Steven J. Long wrote: It looks like there is some consensus on the effort of making systemd more accessible, Sure there is: there's also consensus that this approach is wrong for Gentoo. In my world naysayers have no say and doers decide, as long as there are no obvious negative consequences from doing. In my world it is also an absolute no-brainer to try to make systemd as accessible as possible in Gentoo. Switching init isn't done that often That doesn't mean that it couldn't be, and it also doesn't mean that it wouldn't be handy to use eselect to do so. and when it is a Gentoo user is expected to deal with configuration. I don't know where such expectation could come from since, as you write, switching init isn't done that often; so there can't be a lot of user feedback from doing it, and it hasn't been discussed very much by developers. If you mean that *you* expect users to deal with configuration then that's fine and valid, but I think that if we can find a neat way for users *not* to have to deal with configuration when they want to switch init then that would be really nice! In this case, it's a doddle to set the command-line to init=/sbin/fubar to try it I think it's less about telling the kernel which binary will be process 1 and more about what gets started by process 1 on next boot. If they can't handle the above, they shouldn't be on Gentoo imo. You have all right to your opinion, but I for one don't share this opinion. If we can make it easy to switch around I think that's awesome. I don't see the use-case frankly. I would say that it is to make migration easy. So I just don't see which Gentoo users this is helping. Anyone who has a Gentoo system using OpenRC who would like to try out systemd. Making it even more trivial to change init than it already is, is actually a bad thing in my eyes. It gives the impression that it can be undertaken lightly which is simply bad practice. Sorry, I don't buy your argument. Consider how lightly I can undertake deletion of all my data, which is also bad practise: rm -rf ~ AFAIK it's been policy for a while that systemd unit files should be installed by default, for all the reasons you've given. I can't see a maintainer being bothered by the systemd herd adding them when they have no interest: after all users can already set an INSTALL_MASK, and it makes binpkgs more useful. Yep, +1 for all of this. I think Fabio shouldn't let unresponsiveness of others create very long wait states when doing benign changes. The final outcome will hopefully be: - easier to migrate from/to systemd, at runtime, with NO recompilation at all (just enable USE=systemd and switch the device manager from *udev to systemd -- unless somebody wants to drop the udev part from systemd, if at all possible) How is adding USE=systemd to a system with it switched off (ie: enabling it), *not* going to lead to recompilation? Setting the USE flag doesn't lead to recompilation per se, but the question is good - what will the USE flag actually mean when we arrive at the final outcome? Will it do anything at all? Fabio? In the end, maybe it would just control if baselayout DEPENDs on openrc or systemd? - we make possible to support new init systems in future, and even specific init wrappers (bootchart anyone?) Which is possible already, so this is null. Consider that Fabio and I are not native english speakers. I would recommend spending more time seeking to understand what was intended to be transmitted, rather than merely interpreting the words received. Communication becomes significantly more effectively that way, which you probably don't need me to bring up, if you're used to talking to users on forums. :) - we put back some fun into Gentoo Eh, I've been having much more fun since .. .. the latter is only possible because Unix is designed on a modular basis, and we can still swap components in and out on Linux (for now.) You are implicitly communicating that systemd can not be fun because it is not modular. Basic flaming. What's the point of that? Please note: I fully support your effort to make it easy to switch back and forth I have no doubts that this was true in your original email, but you should consider that the words you chose communicate something very different. I just don't think that adding a fragile eselect module (along with this needs investigation as things come up) is the way to do it. I think the point is to investigate exactly to ensure that the module *is not* fragile. Nor should someone change init on a whim, without being ready to handle configuration. I think it would be awesome if we can allow changing init on a whim, without having to handle configuration. In fact, dumbing down Gentoo is dangerous imo. I think you misinterpret the intention.
Re: [gentoo-dev] Making systemd more accessible to normal users
On Wed, May 1, 2013 at 2:40 PM, Peter Stuge pe...@stuge.se wrote: Steven, I think you can behave a lot better on the internet. kthx. Amazing. I came to the exact opposite conclusion.
Re: [gentoo-dev] Making systemd more accessible to normal users
On Wed, May 01, 2013 at 03:13:54PM +0200, Pacho Ramos wrote: El mié, 01-05-2013 a las 13:00 +0200, Fabio Erculiani escribió: [...] The only remaining problem is about eselect-sysvinit, for this reason, I am probably going to create a new separate pkg called _sysvinit-next_, that contains all the fun stuff many developers were not allowed to commit (besides my needs, there is also the need of splitting sysvinit due to the issues reported in [4]). I am sure that a masked alternative sysvinit ebuild won't hurt anybody and will make Gentoo a bit more fun to use. I am unable to find exact advantage of changing init system without rebooting :/, what is the advantage of booting with an init.d and shutting down with a different one? No, you don't boot with A and shutdown with B. B is loaded by the kernel at the next boot. Switching init system is the only way to roll out a migration path, among other things I already wrote about on the eselect-sysvinit bug. Ah! OK, I misunderstood the runtime sense, in that case looks interesting :D I still don't see the advantage of eselect-sysvinit over editing your boot loader configuration and changing the init= kcl option, as I said on the bug. William signature.asc Description: Digital signature
Re: [gentoo-dev] Making systemd more accessible to normal users
On Wed, May 01, 2013 at 11:14:28PM +0200, Fabio Erculiani wrote: On Wed, May 1, 2013 at 9:52 PM, Paweł Hajdan, Jr. phajdan...@gentoo.org wrote: On 5/1/13 3:04 AM, Fabio Erculiani wrote: As far as I read the bug, Mike (vapier) is doing the right thing. Distros doing lots of custom changes can only add more chaos to the picture. We are a distribution, we have our own goals, thus we change the code to better integrate with our ecosystem. That's part of the game. If we don't want to do that, we shouldn't be running a distro in the first place. Have you reached out to relevant upstreams? If they refuse to make changes, that's a different story. So far I think it's reasonable to go to upstreams first. For just a symlink swap and some file moves? (re: sysvinit) We don't need to bless upstream first for such small changes. Like I've already said too, I don't see that we need to do this change. Systemd is called /usr/lib/systemd/systemd (it should be /lib/systemd/systemd), and sysvinit is called /sbin/init,, so I don't see the need for moving init around and creating all of these symlinks. I guess I'm not completely opposed to it, I just want you to convince me that doing it has value. Where I am now is I feel like it adds complexity for almost no gain. William signature.asc Description: Digital signature
Re: [gentoo-dev] Making systemd more accessible to normal users
On 2 May 2013 15:18, William Hubbs willi...@gentoo.org wrote: Like I've already said too, I don't see that we need to do this change. Systemd is called /usr/lib/systemd/systemd (it should be /lib/systemd/systemd), and sysvinit is called /sbin/init,, so I don't see the need for moving init around and creating all of these symlinks. I guess I'm not completely opposed to it, I just want you to convince me that doing it has value. Where I am now is I feel like it adds complexity for almost no gain. William The best arguments I have for the symlink approach, are: - its a consistent approach that is bootloader agnostic - it doesn't require you to understand your bootloaders scripting system to add it to the init= line - its no brains required, and hard to mess up bootloader configuration under grub1 for instance, was quite straight-forward. Now with grub-2, its quite convoluted, for me at least. Its also sometimes a bit confusing if you need something other than /sbin/init as your init, because sometimes you need some pre-init stuff ( like genkernel does ), and you need some /other/ parameter other than init= so that the pre-init still runs and then passes over to init Having a symlink that will just do the right thing is helpful for these cases. Against, the symlink may introduce parts that are breakable, like if user messes up and places the destination of the symlink on a different partition ( shouldn't be a problem, but might be ), or if you're doing an initird that has init baked into it, you'd have to regenerate that initrd after changing the symlink ( I think, maybe not, its probably not even a problem, its just something I'd have to check ) And also, if for whatever reason systemd becomes unbootable it might be slightly hard to boot with the right init if you can't change kernel parameters during boot time. But noted, those last 2 against reasons are edge cases, where the arguments for it are majority cases, so collectively I'm still in favour of the eselect + symlinks approach. -- Kent
