| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| |
|
|
|
|
| |
I have no idea if this is going to cause rendering problems, and it is fairly
hard to check. So let's just merge this, and if it github markdown processor
doesn't like it, revert.
|
| | |
|
| |
|
|
|
| |
The generator is already merged. So update the corresponding section to
describe the current status.
|
| |
|
|
| |
Most of them were reported by Fossies.org
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
One problem found with the current draft specification is we can't have
an application provide a non-transient systemd service file in a way
that is spec compliant as the service name currently needs to end in a
random token defined by the launcher.
This came up when trying to put DBus activated services into the correct
cgroup. There isn't enough metadata in the DBus service file to know the
correct application ID, and the most intuitive fix is for those
applications to just specify the SystemdService file in the existing
system. They're generally unique for a given user session anyway so
don't need a separate cgroup identifier.
This changes the spec for RANDOM to be optional for services.
It also changes the separator between in services to act like templates.
Ultimately that's what we're trying to recreate with the RANDOM token of
the systemd service and it's a better fit. It's needed as otherwise with
launcher and the random ident being both optional it would be impossible
to get the application ID reliably.
Scopes are unchanged as they don't support templates.
|
| |
|
|
|
|
|
|
|
|
| |
We need both a slice name and a prefix for application units. For
consistency we tried to use the same name and ended up standardising on
"apps.slice" and and "apps-" prefix for the units.
However, "app-" would be a more natural prefix for applications. And it
is no problem to simply also name the slice "app.slice" for consistency
rather than keeping the current "apps.slice".
|
| |
|
|
|
|
| |
Based on a report from Fossies.org using Codespell.
Followup to #15436
|
|
|
This is work in progress and not finished yet. However, I hope to have
captured some of the key points that came up in previous discussions
with appropriate notes about things that still need to be defined.
I may revisit it later. Also, feel free to completely rewrite if the
format is not quite right.
|
