Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 412697 - [PATCH] x11-misc/lightdm - Please add a lightdm.service file for systemd support
Summary: [PATCH] x11-misc/lightdm - Please add a lightdm.service file for systemd support
Status: RESOLVED FIXED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: All Linux
: Normal enhancement (vote)
Assignee: Markos Chandras (RETIRED)
URL: https://bugs.launchpad.net/lightdm/+b...
Whiteboard:
Keywords: PATCH, UPSTREAM
: 468944 (view as bug list)
Depends on:
Blocks: install-systemd-unit
  Show dependency tree
 
Reported: 2012-04-19 21:25 UTC by Ignas A.
Modified: 2013-05-25 14:10 UTC (History)
5 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Ignas A. 2012-04-19 21:25:14 UTC
It would be very nice to have systemd support for lightdm out of the box.

Reproducible: Always

Steps to Reproduce:
1. Install systemd
2. Install lightdm

Actual Results:  
There is no lightdm.service, which can be run by
systemctl enable lightdm.service
or
systemctl start lightdm.service

Expected Results:  
The aforementioned commands should just work

It is pretty straightforward to add one. For example, there is one on:

http://git.overlays.gentoo.org/gitweb/?p=user/sardemff7.git;a=blob_plain;f=x11-misc/lightdm/files/lightdm.service;h=1abd5bd54d588680e966721d15809e12444e6fb8;hb=e0fe5d8cd86418aea0e038643bdbe98fea7d3a42

Tested on ~arch and it works without problems so far.
Comment 1 Markos Chandras (RETIRED) gentoo-dev 2012-05-04 19:07:04 UTC
Why is this not in the upstream code?
Comment 2 Ignas A. 2012-05-04 20:54:12 UTC
I do not know, but according to this bug report, they have several other blockers...

https://bugs.launchpad.net/lightdm/+bug/930488

Sorry, for not looking it earlier in upstream's bug reports...
Comment 3 Markos Chandras (RETIRED) gentoo-dev 2012-05-21 19:04:32 UTC
I am a bit reluctant to apply this patch before upstream merges it
Comment 4 Luis Medinas 2012-06-01 09:25:53 UTC
(In reply to comment #3)
> I am a bit reluctant to apply this patch before upstream merges it

I think you should add the patch because you know... upstream is committed to upstart and NOT to systemd. Maybe they will never support systemd and since this is just a simple unit you can remove it or modified by yourself without waiting for upstream.
Comment 5 Markos Chandras (RETIRED) gentoo-dev 2012-06-02 09:50:37 UTC
That is not true. The upstream bug is still open. If they close it as "IDONTCARE/WONTFIX" then we will support systemd on our own
Comment 6 Luis Medinas 2012-06-02 11:54:53 UTC
(In reply to comment #5)
> That is not true. The upstream bug is still open. If they close it as
> "IDONTCARE/WONTFIX" then we will support systemd on our own

and ? What's the problem of supporting a file with 6 lines ? :)
Comment 7 Markos Chandras (RETIRED) gentoo-dev 2012-06-02 12:57:30 UTC
I don't understand all the pressure. I believe I was clear. First wait for upstream to decide on this matter and then we decide. If you really can't leave without systemd then put it in your local overlay.
Comment 8 Ben de Groot (RETIRED) gentoo-dev 2012-06-26 04:18:52 UTC
As co-maintainer of this package I want to add that I am strongly opposed to adding this patch. If upstream decides to apply it, then it will get installed. But from the Gentoo side we should do nothing to facilitate systemd, as the udev/systemd upstream refuses to work with us, refusing a simple patch from our udev maintainer.
Comment 9 Chí-Thanh Christopher Nguyễn gentoo-dev 2012-09-15 16:44:11 UTC
A separate package containing only the service file could be created (as is done already for e.g. selinux policies)
Comment 10 Markos Chandras (RETIRED) gentoo-dev 2012-09-16 16:12:01 UTC
(In reply to comment #9)
> A separate package containing only the service file could be created (as is
> done already for e.g. selinux policies)

just a package for a simple systemd file is a bit too much I think. This problem has to be fixed upstream first. It is not a Gentoo specific bug and we should not treat it as such.
Comment 11 Markos Chandras (RETIRED) gentoo-dev 2012-11-08 09:33:40 UTC
Ben, what should we do here?
Comment 12 Ben de Groot (RETIRED) gentoo-dev 2013-01-17 07:52:03 UTC
As stated before, this is an upstream issue. In my opinion it is not necessary for us to do anything here.
Comment 13 Markos Chandras (RETIRED) gentoo-dev 2013-05-08 09:54:51 UTC
*** Bug 468944 has been marked as a duplicate of this bug. ***
Comment 14 Markos Chandras (RETIRED) gentoo-dev 2013-05-08 09:55:44 UTC
I believe it is time to reconsider this now that systemd support is spread all over the tree.
Comment 15 Ben de Groot (RETIRED) gentoo-dev 2013-05-08 15:35:42 UTC
(In reply to comment #14)
> I believe it is time to reconsider this now that systemd support is spread
> all over the tree.

I don't think so. If upstream ships it, we will install it. Otherwise we don't. Most Gentoo devs (as well as users) do not use systemd, nor have it installed. I don't think it can be expected of us to test and maintain systemd related patches.

People who really want to use systemd can use the systemd-love overlay. Alternatively, I have suggested on the dev mailing list to put these files in a systemd-units package, so normal package maintainers would not need to be bothered with these.
Comment 16 Fabio Erculiani (RETIRED) gentoo-dev 2013-05-08 15:43:26 UTC
(In reply to comment #15)
> (In reply to comment #14)
> > I believe it is time to reconsider this now that systemd support is spread
> > all over the tree.
> 
> I don't think so. If upstream ships it, we will install it. Otherwise we
> don't. Most Gentoo devs (as well as users) do not use systemd, nor have it
> installed. I don't think it can be expected of us to test and maintain
> systemd related patches.

Why? The systemd team can maintain them.

> 
> People who really want to use systemd can use the systemd-love overlay.
> Alternatively, I have suggested on the dev mailing list to put these files
> in a systemd-units package, so normal package maintainers would not need to
> be bothered with these.

We want the best systemd experience possible in tree, not with some random obscure overlay.
And having a fat one-size-fits-all systemd-units package is just plain wrong, because systemd units should be owned by the respective packages. Conflicts will happen weekly if not bi-weekly as soon as the respective packages start shipping systemd units. And then? how do you ensure that users have a specific unit installed? With once again weird blockers? That's a big NO.
Comment 17 Markos Chandras (RETIRED) gentoo-dev 2013-05-08 15:56:55 UTC
(In reply to comment #15)
> (In reply to comment #14)
> > I believe it is time to reconsider this now that systemd support is spread
> > all over the tree.
> 
> I don't think so. If upstream ships it, we will install it. Otherwise we
> don't. Most Gentoo devs (as well as users) do not use systemd, nor have it
> installed. I don't think it can be expected of us to test and maintain
> systemd related patches.

I expect this to change in the future. We can't keep denying that a new init system exists and we need to at least provide a limited support for it (even though we can't test it ourselves). The overhead is absolutely zero for us to maintain the file. It it works good, if it does not then those who have systemd will fix it or they will suffer.

> 
> People who really want to use systemd can use the systemd-love overlay.
> Alternatively, I have suggested on the dev mailing list to put these files
> in a systemd-units package, so normal package maintainers would not need to
> be bothered with these.

This is wrong. systemd files (just as the init/openrc files) belong to the packages.
Comment 18 Markos Chandras (RETIRED) gentoo-dev 2013-05-18 12:53:38 UTC
systemd file committed. Thank you!

+*lightdm-1.4.0-r2 (18 May 2013)
+
+  18 May 2013; Markos Chandras <hwoarang@gentoo.org> +files/lightdm.service,
+  +lightdm-1.4.0-r2.ebuild:
+  Revbump to add systemd unit file. Thanks to Fabio Erculiani
+  <lxnay@gentoo.org>. Bug #412697
+


http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/x11-misc/lightdm/lightdm-1.4.0-r2.ebuild?view=log

http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/x11-misc/lightdm/files/lightdm.service?view=log
Comment 19 Ben de Groot (RETIRED) gentoo-dev 2013-05-25 05:36:45 UTC
(In reply to comment #17)
> (In reply to comment #15)
> > (In reply to comment #14)
> > > I believe it is time to reconsider this now that systemd support is spread
> > > all over the tree.
> > 
> > I don't think so. If upstream ships it, we will install it. Otherwise we
> > don't. Most Gentoo devs (as well as users) do not use systemd, nor have it
> > installed. I don't think it can be expected of us to test and maintain
> > systemd related patches.
> 
> I expect this to change in the future. We can't keep denying that a new init
> system exists and we need to at least provide a limited support for it (even
> though we can't test it ourselves).

WTF man? No, we do not _need_ to add support for an alternative init system that is so aggressively opposed to what we stand for. But since you pushed this change through against my wishes, I will remove myself as maintainer of this package.
Comment 20 Sergei Trofimovich (RETIRED) gentoo-dev 2013-05-25 07:35:11 UTC
(In reply to comment #19)
> (In reply to comment #17)
> > (In reply to comment #15)
> > > (In reply to comment #14)
> > > > I believe it is time to reconsider this now that systemd support is spread
> > > > all over the tree.
> > > 
> > > I don't think so. If upstream ships it, we will install it. Otherwise we
> > > don't. Most Gentoo devs (as well as users) do not use systemd, nor have it
> > > installed. I don't think it can be expected of us to test and maintain
> > > systemd related patches.
> > 
> > I expect this to change in the future. We can't keep denying that a new init
> > system exists and we need to at least provide a limited support for it (even
> > though we can't test it ourselves).
> 
> WTF man? No, we do not _need_ to add support for an alternative init system
> that is so aggressively opposed to what we stand for. But since you pushed
> this change through against my wishes, I will remove myself as maintainer of
> this package.

Does it have maintenance burden?

-inherit autotools eutils pam readme.gentoo
+inherit autotools eutils pam readme.gentoo systemd
+       systemd_dounit "${FILESDIR}/${PN}.service"

2 noninvasive lines, literally.
Not worse, than libtool files pruning or gentoo's custom Xsession or pam hacks.
Comment 21 Markos Chandras (RETIRED) gentoo-dev 2013-05-25 08:33:38 UTC
(In reply to comment #19)
> (In reply to comment #17)
> > (In reply to comment #15)
> > > (In reply to comment #14)
> > > > I believe it is time to reconsider this now that systemd support is spread
> > > > all over the tree.
> > > 
> > > I don't think so. If upstream ships it, we will install it. Otherwise we
> > > don't. Most Gentoo devs (as well as users) do not use systemd, nor have it
> > > installed. I don't think it can be expected of us to test and maintain
> > > systemd related patches.
> > 
> > I expect this to change in the future. We can't keep denying that a new init
> > system exists and we need to at least provide a limited support for it (even
> > though we can't test it ourselves).
> 
> WTF man? No, we do not _need_ to add support for an alternative init system
> that is so aggressively opposed to what we stand for. But since you pushed
> this change through against my wishes, I will remove myself as maintainer of
> this package.
You seem to have ignored all the discussions in -dev where it was agreed to install systemd files without even a useflag. So really, if you disagree this is your problem since the community agreed to do it.
It is also NOT documented anywhere that Gentoo supports *ONLY* openrc.
Just grep for "systemd_dounit" in the tree and see how many pakcages do that.

It is very sad to be threatened over and over. If I do something then X people will be unhappy. If I do it Y people will be unhappy. So in this case I did what we agreed to do in the mailing list.

You will soon realize that your stance against systemd will make you disagree with more developers in the imminent future.
Comment 22 Tom Wijsman (TomWij) (RETIRED) gentoo-dev 2013-05-25 14:10:09 UTC
(In reply to comment #19)
> WTF man? No, we do not _need_ to add support for an alternative init system
> that is so aggressively opposed to what we stand for.

Eh...

 1) Who is "we"?

 2) What exactly does this "we" people stand for?

 3) Why does "we" stand aggressively opposed to an alternative init system?

If you meant Gentoo, it stands for "... just about any application or need." [1] and I don't see why it would be aggressively opposed to an alternative init system which some of our users are experiencing a benefit from; apart from a rather small group of people that decide to behave strongly opposed to it.

> But since you pushed this change through against my wishes, I will remove myself as maintainer of this package.

If having systemd@g.o (or any other alternative init system, or any other developer permitted by them or a higher instance) add just a few characters you never need to touch and changing an unit file you don't want is too much, then you're just stepping away from the collaborative effort that pursues the goal as stated on the about page of Gentoo; we're all in this together, don't make hate tear you apart. Are you going to stop maintaining any package alternative init system maintainers and users come nag you on? :(

 [1]: http://www.gentoo.org/main/en/about.xml

Hope you would reconsider, it isn't hard to CC systemd@g.o and let them add or change characters that don't stand in your way; in fact, when I'm bug wrangling I've started CC-ing them on any new "systemd unit request" bugs such they can help if the maintainer does not have knowledge in the area.

Similarly, I expect in the near future that OpenRC mantainers (and any other alternative init system maintainers) will do the same; because really, even some of our systemd developers are starting to forget how init files were implemented, nor are they able to easily test them.

At least not until we get eselect init sorted out... :)