-
Notifications
You must be signed in to change notification settings - Fork 1.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Include sway-session.target #5622
Conversation
I'd be happy to see this merged in. It's good for sway as an upstream to provide a standard target, so all other tools, tutorials, etc, can point to a single, same, one, rather than implementing their own with slightly-incompatible differences. |
Thanks for the explanation. What's the end goal with this target?
Do you have examples of other compositors shipping a systemd target file? |
The goal is to let users start systemd services after any graphical session is started, sway being just one example. All other services are expected to depend on The reason for this PR is that So, users will run Does this clarify the workflow? 🙂
I haven't looked in detail, for example GNOME ships a very sophisticated list of targets, we don't really need that complexity. |
There's a good description of
|
I don't have a strong preference but I thought if we add By the way |
The Documentation directive is a list. Many units have several man pages, hyperlinks etc. listed, and in this case we can too. I don't see any reason not to direct users to all the relevant documentation if there are several relevant pages. Especially since more users seem to be confused on the purpose of the target than sway's behavior...
That's not the real utility of graphical.target. The systemd.special(7) man page describes the purpose of graphical.target like so:
Which is a reasonable function, I think. Tray icon applets and notifications daemons are probably the intended users of this. The man page gives gnome-settings-daemon as its motivating example. Basically any program related to the graphical session which might not be prompted to close by losing connection to a Wayland display. This behavior is why the man page recommends units specify Autostarting apps is simple enough without a target. systemd even provides systemd-xdg-autostart-generator for a method based on XDG autostart. But I think the intended purpose described by the man page is the more novel and useful behavior. |
Merging this PR would help other packagers to rely on It would be a bit of a mess now if multiple sway-specific background services wanted to depend on a sway target, as they would all end up shipping |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Really looking forward to seeing this merged.
It'll make it easier for applications to include a systemd.service
unit file that depends on a standardised target.
TBH I'd rather let systemd distributions add the target themselves. If they're going to add one line to their distro-specific config file, having to add a 3-line file isn't a big deal. |
@emersion the challenge is there's a whole ecosystem of related projects. In the world where all systemd distributions who wanted this added exactly the same file with exactly the name The option proposed here is to ship the systemd file in the core project, providing a canonical target name for every distro to use, eliminating the risk of differences and the need to coordinate between distros for this detail. |
Services should be started on |
@emersion Thanks for the reply. Are there specific questions left to discuss before a merge/no-merge decision is made? |
It's undeniable that it'll require downstream changes by some. Right now, but
Some services are sway-specific and this target is for those. |
Co-authored-by: Hugo Barrera <hugo@barrera.io>
For Fedora we needed a bit more than just a session target, so I extracted all my relevant configs and scripts into alebastr/sway-systemd and currently working on adding that as a recommended dependency for our If you think your distribution can leverage that, feel free to take the configs, provide feedback or contribute. I certainly wouldn't mind making that a cross-distribution effort. |
@alebastr I'm bookmarking the project and may try it on Arch Linux. I'll provide feedback through the I reviewed the |
Is there anything blocking this from being merged? I realise it's not critical, but it's definitely a nice-to-have, and I can't see if having any negative side-effects. |
This is now 2.5 years old, and I see there has been very little movement on it. From my perspective, this is a fix that will benefit many people using sway while giving almost 0 burden to sway maintainers. Any arguments about "distros should handle this" are, quite frankly, If there is no standardization then 3rd party sway services have absolutely no way of knowing how to start after sway has started. Each distro can be free to choose The only downsides I've heard from sway developers fall into two arguments:
I would argue that a 6 line INI file that is not connected to any particular API is not a maintenance burden. I would also argue that explicitly not supporting "an init system" is the same thing as choosing a side. Please consider merging this. |
Calling maintainer arguments delusional is not a particularly productive way to lead a discussion. :)
The only question is who owns the "6 line INI file": a service-manager agnostic project which has historically avoided this sort of thing, or distribution packages that normally contain whatever integrations are relevant to their distribution-specific design decisions. |
Incorrect, sway provides an IPC socket that services cannot know is ready solely based off of
Service-manager agnostic is not the same thing as service manager antagonistic. Sway does not support login mangers but ships a |
it would be an error for a service definition to rely on a sway-specific
target
I have services that I want to launch that are Sway-specific. They need a
Sway-specific target. They don't make sense in Gnome or other other
environments or they use the Sway IPC.
…On Wed, Apr 26, 2023 at 8:40 AM LaserEyess ***@***.***> wrote:
The ability to target sway-session.target from a service file is *not*
the goal of this change, and it would be an error for a service definition
to rely on a sway-specific target.
Incorrect, sway provides an IPC socket that services *cannot* know is
ready solely based off of graphical-session.target. Again, this is not
about the wayland session, you can use
ConditionEnvironment=WAYLAND_DISPLAY for that.
a service-manager agnostic project which has historically avoided this
sort of thing, or distribution packages that normally contain whatever
integrations are relevant to their distribution-specific design decisions.
Service-manager agnostic is not the same thing as service manager
antagonistic. Sway does not support login mangers but ships a sway.desktop
file at the top level of this repository despite its only purpose being to
enable usage by login managers. This is also a 6 line INI file that has
effectively 0 maintenance burden for developers. What is the difference
here?
—
Reply to this email directly, view it on GitHub
<#5622 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAAGJZPJX5FO2BRQKLQLRJ3XDEJTDANCNFSM4P7XC44A>
.
You are receiving this because you commented.Message ID:
***@***.***>
--
*Mark Stosberg* (he/him)
Director of Systems & Security
***@***.*** | 765.277.1916
https://www.rideamigos.com <https://rideamigos.com/>
Changing the way the world commutes.
<https://www.linkedin.com/company/rideamigos>
<https://www.twitter.com/rideamigos> <https://www.facebook.com/rideamigos>
<https://www.instagram.com/rideamigos>
<https://rideamigos.com/newsletter-sign-up/>
|
This is not the goal of this PR. The goal of this PR as per its description is to trigger graphical-session.target that other packages might be relying on, which for technical reasons require an intermediate target. This original intent does have some merit, but I am not a fan of the alternate uses that have cropped up in the discussion.
The .desktop file is a freedesktop specification supported by numerous login managers and platforms. While not pretty, it is not against any of our policies (not supporting login managers just mean that we will not debug GDM problems for you). The equivalent to a systemd service file would instead be if we carried a GDM-specific login manager configuration. Regardless, trying to nitpick on our values and policies is also not a particularly productive way to discuss things. You are not trying to defeat a machine with errors in its logic, but are trying to convince human meatbags to change their ideologies and opinions. :)
This is a perfect counter-example for direct usage of a sway-specific target: Turning "not for gnome" into "strictly for sway" in a packaged service definition is unfriendly to users and the Wayland ecosystem as a whole, which may wish to use the service on a different, but otherwise compatible and sensible Wayland server. Even sway IPC is not sway specific, as it is i3's IPC system with a few sway extensions. For the limited number of applications that rely on sway IPC, the recommended way to start these are with an |
This is not about your values or opinions, this is about what currently exists in the repository. A desktop file was added and in ~8 years it has changed exactly once: to update a comment. It has not been an explicit endorsement of login managers nor explicit support. It does not require to sacrifice or betray any ideologies, and I'm sure the dev team does have some opinions about freedesktop.org. A Can it be abused by 3rd party projects to erroneously depend on it for wayland sessions when they should be using |
Whether we merge this PR is purely a matter of our opinion of it, with the primary blocker being our opinion of hosting service manager specific - to some extend especially systemd-specific - files and features. This kind of change has a default NACK policy due to our ideologies around favoritism and the resulting implicit lock-in that we do not think belongs in good FOSS. I am tempted to ACK it, but the recent arguments have only been around usages that I am not at all interested in providing new mechanisms for. I am only interested in helping sway fit into a generic ecosystem of pre-existing |
I think discussion is went beyond just justifying some standing point. I don't think stakes are so high here 😛. If this PR is to reduce patches by distros which ideally should be zero, then it should also include target activation script. Sway wiki for SystemD is nice. But in case if many distros and LFS users have to do it anyway. Why not just make it easier to use for majority cases? P.S. Not a heavy systemd user.
Can't we use |
A sway-session.target has utility in a systemd environment because graphical-session.target has utility, and that is how the systemd documentation directs graphical-session.target to be used (rather than started directly). Really it's just a suggestion for how to use sway within systemd. The wiki is an acceptable place for this file but so is the repo imo. Ideally the distro would carry this as necessary but I don't think its too much trouble to help them out here, especially since Arch at least has got it wrong atm. I personally use a similar target in place of Arch's 50-systemd-user.conf just as suggested in the OP and I don't start sway as a user service.
The ConditionEnvironment directive isn't very useful in either case. One generally just wants a dependency ordering here, not conditional execution. Sway does ensure both vars are set before "exec" commands are run though. The trouble on systemd on some distros is that the vars may not yet be available in the user service manager's environment block until The file is small and distros can ignore it if they want. I don't think it really contributes to lock-in in the same way that say linking libsystemd would, and we also provide that as an option. |
|
Even with this target, users still need "glue" in their sway config to actually trigger this target once sway has initialised. The target file could contain a comment that instructs to user how to do this. E.g., something like:
Edit: actually, users still need to import things like I'll also point out that systemd supports only one concurrent user session at a time (this is a known limitation). If you log in on a second tty, the existing systemd instance is shared, so the sway instance on that second tty wouldn't have any services run for it. It would also mess up systemd's service environment and when services (re)start, they would run on the second sway instance, or fail to start after the second sway instance exits (even if the first is still running). |
Hmm, the "systemd integration" section of the wiki seems like a fine location for this indeed, and in fact it already seems to be present there (https://github.com/swaywm/sway/wiki/Systemd-integration#managing-user-applications-with-systemd). We already have content in that section that we disagree even more with anyway (running sway itself as a user service). With that in mind, NACK on a PR that puts it in the repo. |
Having this is the wiki is not a substitute for having it in the repository and available for installation by downstream. The point of this file is to provide this functionality for 3rd party projects, and to standardize it so downstream (distros) do not have to carry patches for this. There is absolutely no chance of standardization happening at the distro level, none. If this is such an affront to the ideologies of the maintainers then perhaps it could be gated behind systemd support: if sdbus.name() == 'libsystemd'
install_data('sway-session.target', install_dir: systemd_install_dir)
endif Now BSDs and devuan won't be poisoned with the file. |
I'm in favor of merging this, but I'm also in favor of OSS maintainer's right to choose. In this case, the problem is solved by the https://repology.org/project/sway-systemd/versions The package is easy to find if you search for sway and systemd and other distros are welcome to package it. Besides providing a target file, this package takes care of a few other details of sway/systemd integration that people are likely to also want-- features that are also unlikely to be merged in the Sway repo. Considering this context, I'm also supportive of rejecting this PR in favor of that, because even closing the issue provides some clarity on the issue and can be seen as an endorsement of that alternative. |
You are my hero @maximbaz \o/ For maintainers: please merge this. It is the lighter weight option; I prefer to manage my own user units using dotfile management (chezmoi). Adding this service and the right incantation in the sway config file is just what I wanted. |
Contrib has been moved to an external repository: https://github.com/OctopusET/sway-contrib Maybe this file can find a home there? |
Submitted to third-party repo: OctopusET/sway-contrib#6 It still seems like it would be better if that sway-contrib repo were under the umbrella of the Sway github organization. The contrib project could be granted different managers so it could still be independent. |
Closing it as it has been merged in sway-contrib |
In order to keep the discussion focused: this PR is NOT about running sway as a systemd service 🙂
sway
can run on many OS, some of which usesystemd
for service management, like Arch Linux.On those OS it is needed to organize dependencies and startup order, for example some services should only start in a graphical session, but not in tty, and should stop when graphical session ends.
For this particular task,
systemd
itself created a standardgraphical-session.target
, which as per their description acts as a dynamic alias for any concrete graphical user session (so a service that must only run in a graphical session would declare a dependency on this virtual target).According to this design,
graphical-session.target
itself should not and cannot be started directly, instead every WM should provide its own.target
that "implements" this interface.sway wiki contains the definition of
sway-session.target
and instructions for users on where to put it, however given thatsystemd
is popular, I propose to includesway-session.target
directly in the repo. This would help consolidating the effort and share best-practices between people who run OS withsystemd
and who compilesway
(for themselves or especially as part of creatingsway
distro packages), as they would additionally copy this.target
(the same one!) to a proper location as part ofsway
package, instead of users having to do so..target
present in sway repo has nothing to do with howsway
itself is being launched..target
installed on an end-user's computer does not change any behavior in itself, users still need to start and stop it themselves.systemctl --user start sway-session.target
to that file.Looking forward to your feedback 🙂