Re: [gentoo-dev] Making systemd more accessible to "normal" users
On Wed, May 8, 2013 at 9:18 PM, Walter Dnes 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 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 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" 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 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 I don't run "desktop environments"; I run useful applications
Re: [gentoo-dev] extending metadata.xml to support CPE information
On Wednesday 08 May 2013 21:01:19 Mike Frysinger wrote: > On Tuesday 07 May 2013 23:59:18 Mike Frysinger wrote: > > we've already got a database for maintaining this sort of thing on a per- > > package basis: metadata.xml. so let's extend the DTD to cover this. the > > existing remote-id field looks like a pretty good fit, so the proposal is > > simple: add a new "cpe" type. > > committed: or not. someone on cc want to commit that change for me ? :) just add "cpe" between "cpan-module" and "cran" in the remote-id field. -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] extending metadata.xml to support CPE information
On Tuesday 07 May 2013 23:59:18 Mike Frysinger wrote: > we've already got a database for maintaining this sort of thing on a per- > package basis: metadata.xml. so let's extend the DTD to cover this. the > existing remote-id field looks like a pretty good fit, so the proposal is > simple: add a new "cpe" type. committed: http://sources.gentoo.org/gentoo/xml/htdocs/dtd/metadata.dtd?r1=1.12&r2=1.13 --- metadata.dtd31 Dec 2012 21:10:30 - 1.12 +++ metadata.dtd9 May 2013 01:00:39 - @@ -64,7 +64,7 @@ - + -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] [PATCH] gnome2.eclass does not respect ECONF_SOURCE
On Wednesday 05 December 2012 18:02:51 Doug Goldstein wrote:
> - if grep -q "disable-scrollkeeper" configure; then
> + if grep -q "disable-scrollkeeper" ${ECONF_SOURCE:-.}/configure; then
ECONF_SOURCE should be quoted
-mike
signature.asc
Description: This is a digitally signed message part.
Re: [gentoo-dev] OpenRC supporting systemd units
On 05/08/2013 04:06 PM, Chí-Thanh Christopher Nguyễn wrote: > Michael Mol schrieb: >>> Sounds like a great feature. A crashed process is a buggy one, and I >>> would want to investigate said program before I relaunched it, and >>> not have it automatically relaunched as if nothing had happened. >> >> That's highly, highly, highly use-case dependent. If it's a >> non-critical service, or in a non-critical environment, that's one >> thing. If it's a service whose downtime can be measured in value lost, >> that's quite another. > > You could be looking at someone trying to compromise your system through a > buffer overflow or similar vulnerability. If you enable automatic respawn > then congratulations, you just gave the attacker unlimited tries to guess > the correct address/offset for his exploit. Without respawn, you're already bending over and taking a DoS. And when you're in a situation where service uptime is a cap on revenue, uptime is pretty darn important. That's not to say analyzing the crash isn't important, but if I allowed a prod service to remain down while I investigated a crash, studied the problem, evaluated a fix for correctness and lack of regressions, scrubbed the fix and tried again, I wouldn't have that job for very long! Certainly there are environments where it's sensible to take things slow while you investigate (OpenVPN crashed? ssh crashed?), but there are environments where that's not the case, too. It depends on your threat model and a variety of cost/analysis factors. That's why I said "highly, highly, highly use-case dependent." If upstream provides a unit file, and that unit file specifies a behavior, you should (by default) trust the upstream. If you don't like what upstream does, convince them to change. If they won't, make your changes locally. If it's _really_ bad, obviously you have an interesting position as a dev in a distribution, and you might make your change there, but that certainly shouldn't be your default course of action. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] OpenRC supporting systemd units
On Wed, May 8, 2013 at 4:06 PM, Chí-Thanh Christopher Nguyễn wrote: > You could be looking at someone trying to compromise your system through a > buffer overflow or similar vulnerability. If you enable automatic respawn > then congratulations, you just gave the attacker unlimited tries to guess > the correct address/offset for his exploit. Hence the reason it is highly use-case dependent. The same could be said of inittab restarting agetty indefinitely. You can configure rate-limiting on restarts, etc. Somebody mentioned fork-bombs and cgroups. From what I can read when a systemd restarts something it first stops it and then starts it. Stopping a unit by default involves sending SIGTERM followed by SIGKILL to the cgroup. In general your processes won't be getting away unless they're root and manipulating such things. Much of the systemd behavior is configurable though - you could configure a unit to only kill the "main" process, and for that matter you can configure how systemd figures out the PID of the "main" process. This is getting a bit off-topic though. I doubt anybody is going to want default behavior on a systemd unit to be to auto-restart, unless you're talking about stuff that already goes into inittab. If anybody wants stuff to auto-restart they'll edit their unit files (so files in /etc should override files elsewhere, or they should get config protection). Rich
Re: [gentoo-dev] OpenRC supporting systemd units
Michael Mol schrieb: >> Sounds like a great feature. A crashed process is a buggy one, and I >> would want to investigate said program before I relaunched it, and >> not have it automatically relaunched as if nothing had happened. > > That's highly, highly, highly use-case dependent. If it's a > non-critical service, or in a non-critical environment, that's one > thing. If it's a service whose downtime can be measured in value lost, > that's quite another. You could be looking at someone trying to compromise your system through a buffer overflow or similar vulnerability. If you enable automatic respawn then congratulations, you just gave the attacker unlimited tries to guess the correct address/offset for his exploit. Best regards, Chí-Thanh Christopher Nguyễn
Re: [gentoo-dev] OpenRC supporting systemd units
On Wed, May 8, 2013 at 2:55 PM, Ambroz Bizjak wrote: >> Init.d scripts are programs - they could probably do just about anything. > > They couldn't monitor a process and restart it when it crashes, as > specified by the restart options in the unit file. That is, without > significant modifications in the way OpenRC works, such as adding a > monitoring process, or hacks such as launching a daemon that monitor > that process specifically. Sure. I doubt anybody is suggesting that OpenRC would expand the full feature set of systemd anyway (if it did the people who don't want to use systemd would likely fork it back to where it is now anyway). A unit can support dozens of options, but for the most part you can get by with just a few. I'm sure any support across the two systems would start with the few features that get people 90% of the way there. If somebody wants to have their processes propped up, they can install systemd. Ditto for launching daemons in containers, implementing xinetd, and all the other bells and whistles systemd offers. All we really need to get working from a basic usability standpoint is stuff like what to launch, what UID/niceness/etc to use, and what the deps are - the stuff in the typical skeleton init.d script. Really all you need is some code at the top of the existing init.d script that just populates some environment variables based on values translated from the unit file and then invokes the typical current logic. The biggest issue I'd see would be around dependency translation. Assuming our units use the same names as our existing package init.d scripts (likely) that isn't a problem in most cases, but dependencies on targets/etc in systemd might need a little handling. I'm not really a systemd guru yet so I'm sure I'm oversimplifying, but as long as any translation focuses only on what openrc already supports it shouldn't be a big problem. Rich
Re: [gentoo-dev] OpenRC supporting systemd units
Jeroen Roovers schrieb: > Sounds like a great feature. A crashed process is a buggy one, and I > would want to investigate said program before I relaunched it, and not > have it automatically relaunched as if nothing had happened. Even worse if it keeps on thinking that the process has crashed when it actually hasn't. Then it launches another instance, effectively creating a forkbomb. Though proper use of cgroups does prevent this. Best regards, Chí-Thanh Christopher Nguyễn
Re: [gentoo-dev] OpenRC supporting systemd units
On 05/08/2013 03:18 PM, Jeroen Roovers wrote: > On Wed, 8 May 2013 20:55:35 +0200 > Ambroz Bizjak wrote: > >>> Init.d scripts are programs - they could probably do just about >>> anything. >> >> They couldn't monitor a process and restart it when it crashes, as >> specified by the restart options in the unit file. That is, without >> significant modifications in the way OpenRC works, such as adding a >> monitoring process, or hacks such as launching a daemon that monitor >> that process specifically. > > Sounds like a great feature. A crashed process is a buggy one, and I > would want to investigate said program before I relaunched it, and not > have it automatically relaunched as if nothing had happened. That's highly, highly, highly use-case dependent. If it's a non-critical service, or in a non-critical environment, that's one thing. If it's a service whose downtime can be measured in value lost, that's quite another. I've had setups where, yes, I had it respawn. But I also wanted it to send me a core dump so I could investigate. Were I in that circumstance again, I'd automate collection and analysis of the dumps to produce heat maps for me. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] OpenRC supporting systemd units
On Wed, 8 May 2013 13:32:01 -0500 William Hubbs wrote: > On Wed, May 08, 2013 at 07:07:17PM +0200, Michał Górny wrote: > > It is quite likely that OpenRC will start supporting unit files soon. > > Then in many cases we will be able to strip down this to just one init > > format which would satisfy both init systems. > > Do you want to fill me in? ;-) I haven't seen or heard of any work to > make this happen. http://wiki.gentoo.org/wiki/Google_Summer_of_Code/2013/Ideas/OpenRC_Improvements -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] OpenRC supporting systemd units
On Wed, 8 May 2013 20:55:35 +0200 Ambroz Bizjak wrote: > > Init.d scripts are programs - they could probably do just about > > anything. > > They couldn't monitor a process and restart it when it crashes, as > specified by the restart options in the unit file. That is, without > significant modifications in the way OpenRC works, such as adding a > monitoring process, or hacks such as launching a daemon that monitor > that process specifically. Sounds like a great feature. A crashed process is a buggy one, and I would want to investigate said program before I relaunched it, and not have it automatically relaunched as if nothing had happened. jer
Re: [gentoo-dev] Deptree broken - remove keyword on many packages, or downgrade profile to "dev"?
On 5/8/13 2:56 AM, Andreas K. Huettel wrote: > the deptree of kde-base has been broken for over two months now (most likely > more, it was already bad for a while when I filed bug 460532), and we cannot > really commit new KDE releases without repoman --force option. > > A package is missing keyword ~amd64-fbsd, and so far noone from that team has > responded to our repeated communication attempts. > > For the KDE team, I see two options: > 1) remove amd64-fbsd keyword everywhere. This is "within our rights to do", > but hits users badly (if there are any). > 2) downgrade the amd64-fbsd profiles from "stable" to "dev" in > profiles/profiles.desc. This has the big advantage that the impact for users > is minimal, but enables us to work normally again at the same time. Needless > to say, it's not really a usual step to take for anyone outside the > amd64-fbsd > team. > > Out of frustration I am slowly tending to just commit option 2 and take the > resulting flak. I support anything done to unbreak the tree. If possible, masking USE flags or packages on amd64-fbsd sounds better than switching the whole profile to dev, which is likely to introduce even more breakages. Paweł signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] OpenRC supporting systemd units
> Init.d scripts are programs - they could probably do just about anything. They couldn't monitor a process and restart it when it crashes, as specified by the restart options in the unit file. That is, without significant modifications in the way OpenRC works, such as adding a monitoring process, or hacks such as launching a daemon that monitor that process specifically. On Wed, May 8, 2013 at 8:45 PM, Rich Freeman wrote: > On Wed, May 8, 2013 at 2:32 PM, William Hubbs wrote: >> >> OpenRC can't support units directly; if this ever did happen it would >> have to be a tool that converts units to init scripts. > > Or an init script skeleton that interprets a unit file. That seems > like it shouldn't be too hard to write for a limited number of systemd > features. Just point the conf.d file to the unit file, or use a > convention for where the init.d script looks for the unit. > > Init.d scripts are programs - they could probably do just about anything. > > Rich >
Re: [gentoo-dev] OpenRC supporting systemd units
On Wed, May 8, 2013 at 2:32 PM, William Hubbs wrote: > > OpenRC can't support units directly; if this ever did happen it would > have to be a tool that converts units to init scripts. Or an init script skeleton that interprets a unit file. That seems like it shouldn't be too hard to write for a limited number of systemd features. Just point the conf.d file to the unit file, or use a convention for where the init.d script looks for the unit. Init.d scripts are programs - they could probably do just about anything. Rich
[gentoo-dev] OpenRC supporting systemd units
On Wed, May 08, 2013 at 07:07:17PM +0200, Michał Górny wrote: > It is quite likely that OpenRC will start supporting unit files soon. > Then in many cases we will be able to strip down this to just one init > format which would satisfy both init systems. Do you want to fill me in? ;-) I haven't seen or heard of any work to make this happen. OpenRC can't support units directly; if this ever did happen it would have to be a tool that converts units to init scripts. William signature.asc Description: Digital signature
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 wrote: > > On Wed, May 8, 2013 at 5:39 PM, Chí-Thanh Christopher Nguyễn > > wrote: > >> Ben de Groot schrieb: > >>> On 1 May 2013 18:04, Fabio Erculiani 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
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 Wed, May 08, 2013 at 11:49:18PM +0800, Ben de Groot wrote: > On 8 May 2013 23:39, Fabio Erculiani wrote: > > On Wed, May 8, 2013 at 5:26 PM, Ben de Groot wrote: > >> On 1 May 2013 18:04, Fabio Erculiani 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
On Wed, May 8, 2013 at 1:18 PM, Michael Mol 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, 08 May 2013 13:18:57 -0400 Michael Mol wrote: > On 05/08/2013 01:08 PM, Michał Górny wrote: > > On Wed, 8 May 2013 23:26:57 +0800 > > Ben de Groot wrote: > > > >> On 1 May 2013 18:04, Fabio Erculiani 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 05/08/2013 01:08 PM, Michał Górny wrote: > On Wed, 8 May 2013 23:26:57 +0800 > Ben de Groot wrote: > >> On 1 May 2013 18:04, Fabio Erculiani 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, 8 May 2013 23:26:57 +0800 Ben de Groot wrote: > On 1 May 2013 18:04, Fabio Erculiani 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... -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] Making systemd more accessible to "normal" users
On Thu, 9 May 2013 00:21:53 +0800 Ben de Groot wrote: > On 8 May 2013 23:49, Fabio Erculiani wrote: > > On Wed, May 8, 2013 at 5:39 PM, Chí-Thanh Christopher Nguyễn > > wrote: > >> Ben de Groot schrieb: > >>> On 1 May 2013 18:04, Fabio Erculiani 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. It is quite likely that OpenRC will start supporting unit files soon. Then in many cases we will be able to strip down this to just one init format which would satisfy both init systems. Of course, people who are thoughtlessly removing all systemd files for the sake of 4 KiB will suffer then. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] Making systemd more accessible to "normal" users
On 8 May 2013 21:51, Ben de Groot 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 Wed, May 8, 2013 at 11:26 AM, Ben de Groot 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
Mike Gilbert schrieb: > On Wed, May 8, 2013 at 12:06 PM, Chí-Thanh Christopher Nguyễn > 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
-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 > wrote: >> On 8 May 2013 23:39, Fabio Erculiani wrote: >>> On Wed, May 8, 2013 at 5:26 PM, Ben de Groot >>> 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
-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 wrote: >> On Wed, May 8, 2013 at 5:26 PM, Ben de Groot >> wrote: >>> On 1 May 2013 18:04, Fabio Erculiani 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
On 8 May 2013 23:49, Fabio Erculiani wrote: > On Wed, May 8, 2013 at 5:39 PM, Chí-Thanh Christopher Nguyễn > wrote: >> Ben de Groot schrieb: >>> On 1 May 2013 18:04, Fabio Erculiani 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
On Wed, May 8, 2013 at 12:06 PM, Chí-Thanh Christopher Nguyễn 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
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 11:49 AM, Ben de Groot wrote: > On 8 May 2013 23:39, Fabio Erculiani wrote: >> On Wed, May 8, 2013 at 5:26 PM, Ben de Groot wrote: >>> On 1 May 2013 18:04, Fabio Erculiani 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
On Wed, May 8, 2013 at 5:49 PM, Ben de Groot wrote: > On 8 May 2013 23:39, Fabio Erculiani wrote: >> On Wed, May 8, 2013 at 5:26 PM, Ben de Groot wrote: >>> On 1 May 2013 18:04, Fabio Erculiani 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 05/08/2013 11:39 AM, Chí-Thanh Christopher Nguyễn wrote: > Ben de Groot schrieb: >> On 1 May 2013 18:04, Fabio Erculiani 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:39 PM, Chí-Thanh Christopher Nguyễn wrote: > Ben de Groot schrieb: >> On 1 May 2013 18:04, Fabio Erculiani 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 8 May 2013 23:39, Fabio Erculiani wrote: > On Wed, May 8, 2013 at 5:26 PM, Ben de Groot wrote: >> On 1 May 2013 18:04, Fabio Erculiani 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
Ben de Groot schrieb: > On 1 May 2013 18:04, Fabio Erculiani 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 Wed, May 8, 2013 at 5:26 PM, Ben de Groot wrote: > On 1 May 2013 18:04, Fabio Erculiani 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
On 1 May 2013 18:04, Fabio Erculiani 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] Deptree broken - remove keyword on many packages, or downgrade profile to "dev"?
On Wed, 08 May 2013 11:56:51 +0200 "Andreas K. Huettel" wrote: > > Hiya everybody, > > the deptree of kde-base has been broken for over two months now (most > likely more, it was already bad for a while when I filed bug 460532), > and we cannot really commit new KDE releases without repoman --force > option. > > A package is missing keyword ~amd64-fbsd, and so far noone from that > team has responded to our repeated communication attempts. You know, you can email me directly (or even better: the arch alias) if you want a quick response, no need to go through -dev ;) I don't think I was slow on answering on bug #455960 : I didn't understand what was needed and from the quick checks I made back then everything was fine. It took you one month to open bug #460532 and now you come with threats because you had no answer for 2 months, please ;) Had you emailed me, I would have answered: I don't have time to do amd64-fbsd work atm, it'll be better in June. Meanwhile, there is profiles/arch/amd64-fbsd/todo/package.use.mask for these cases (see comments at the top of the file). For this precise case, you can either wait for me to do it properly, or, which is bad but, what I've just done to save all the tears: keyword nepomuk-widgets (it is split out of nepomuk IIUC so should be fine as a "version bump"). As for taglib, it doesn't build IIRC, so you can add the relevant entry to the above mentioned package.use.mask file when needed. If you want to avoid this in the future, please don't commit packages with broken deps :) Alexis.
[gentoo-dev] Deptree broken - remove keyword on many packages, or downgrade profile to "dev"?
Hiya everybody, the deptree of kde-base has been broken for over two months now (most likely more, it was already bad for a while when I filed bug 460532), and we cannot really commit new KDE releases without repoman --force option. A package is missing keyword ~amd64-fbsd, and so far noone from that team has responded to our repeated communication attempts. For the KDE team, I see two options: 1) remove amd64-fbsd keyword everywhere. This is "within our rights to do", but hits users badly (if there are any). 2) downgrade the amd64-fbsd profiles from "stable" to "dev" in profiles/profiles.desc. This has the big advantage that the impact for users is minimal, but enables us to work normally again at the same time. Needless to say, it's not really a usual step to take for anyone outside the amd64-fbsd team. Out of frustration I am slowly tending to just commit option 2 and take the resulting flak. Opinions? (Mr_Bones, please help me shouting!) Cheers, Andreas -- Andreas K. Huettel Gentoo Linux developer dilfri...@gentoo.org http://www.akhuettel.de/
