Skip to content
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

freedesktop modules: init #45058

Merged
merged 3 commits into from Aug 30, 2018
Merged

Conversation

michaelpj
Copy link
Contributor

Motivation for this change

Follow-up to/supersedes #44866.

This adds some modules that handle various parts of the XDG specs. This allows us to move some of the logic out of system-path.nix, and have a more sensible way to decide whether to update MIME caches.

I then added an option to system-path to allow extra environment setup commands to be defined by other modules, so the MIME module can also have the setup code in it.

Points I'm unsure about

  • Should the XDG modules be enabled by default? Lots of things probably assume they are, but I could see the argument for not doing so. Currently all the DEs turn them on, so off by default would mean that a machine without a DE or X would also not have all the MIME stuff linked in, and so on.
  • I wasn't brave enough to try and have a module controlling the use of the base directory spec - this is pretty deeply woven into everything, so I'm not sure that gains us much. However, it would give us a central location to define the constants /share and /etc/xdg, which might have some value.
  • Is the extraSetup mechanism for system-path OK? It's a bit ugly that clients use $out to be the output of another derivation.

@jtojnar @vcunat

Things done
  • Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS)
  • Built on platform(s)
    • NixOS
    • macOS
    • other Linux distributions
  • Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
  • Tested compilation of all pkgs that depend on this change using nix-shell -p nox --run "nox-review wip"
  • Tested execution of all binary files (usually in ./result/bin/)
  • Determined the impact on package closure size (by running nix path-info -S before and after)
  • Fits CONTRIBUTING.md.

@Mic92
Copy link
Member

Mic92 commented Aug 15, 2018

it could be also enabled if a display manager is enabled. Afaik it also make sense in the context of window managers like awesome or i3.

type = types.bool;
default = true;
description = ''
Whether to install files to support the XDG Dekstop Menus specification.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

typo dekstop

@@ -38,9 +38,6 @@ in
QT_PLUGIN_PATH = [ "/lib/qt4/plugins" "/lib/kde4/plugins" ];
QTWEBKIT_PLUGIN_PATH = [ "/lib/mozilla/plugins/" ];
GTK_PATH = [ "/lib/gtk-2.0" "/lib/gtk-3.0" ];
XDG_CONFIG_DIRS = [ "/etc/xdg" ];
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Where did this go?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Whoops, left over from when I did try having a base-directories module.

@@ -107,12 +107,8 @@ in
"/etc/gtk-3.0"
"/lib" # FIXME: remove and update debug-info.nix
"/sbin"
"/share/applications"
"/share/desktop-directories"
"/share"
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why this? The rest of the share subdirectories in pathsToLink would be pointless then. I think we want to avoid "/share" (principle of least privilege or something).

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hm, I think I was confused by the need for /etc/xdg but not /share - I think you're right that it will do the right thing because we typically include subdirectories of /share explicitly.

@michaelpj
Copy link
Contributor Author

Hm, good point about non-DE environments. xserver.nix also enables them, perhaps that's enough and I should remove the ones in the DE modules? OTOH, not sure how that will play with Wayland.

@jtojnar
Copy link
Contributor

jtojnar commented Aug 15, 2018

For Wayland, we still use xserver module (#43992, #44497). There might be some refactoring in the future, but for now, I think it is a good place as any.

@michaelpj
Copy link
Contributor Author

Okay, I've removed the settings in the DEs, relying on the xserver module to set the option.

environment.extraSetup = ''
XDG_DATA_DIRS=$out/share ${pkgs.shared-mime-info}/bin/update-mime-database -V $out/share/mime > /dev/null

${pkgs.desktop-file-utils}/bin/update-desktop-database $out/share/applications
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This should be probably separate from mime module. After all, the applications dir is also used by desktop-entry-spec and menu-spec.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, but I believe that update-desktop-database only performs actions relevant to MIME lookup, so I think it belongs here.

config = mkIf config.xdg.menus.enable {
environment.pathsToLink = [
"/share/applications"
"/share/applications-merged"
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It looks like it should be share/menus/applications-merged: https://specifications.freedesktop.org/menu-spec/menu-spec-latest.html#paths

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah yes, good spot.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fixed.

@jtojnar
Copy link
Contributor

jtojnar commented Aug 15, 2018

The original code checked for existence of the directory used for generating the caches, can we make sure that the generators work even with the directory possibly missing?

@@ -0,0 +1,21 @@
{ config, lib, pkgs, ... }:
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Unused pkgs arg

type = types.bool;
default = true;
description = ''
Whether to install files to support the XDG Autostart specification.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It would be nice to have a link to the specification <link xlink:href="https://specifications.freedesktop.org/autostart-spec/autostart-spec-latest.html">XDG Autostart specification</link>

extraSetup = mkOption {
type = types.lines;
default = [ ];
description = "Shell fragments to be run after the system environment has been created. This should only be used for things that need to modify the internals of the environment, e.g. generating MIME caches.";
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe mention something about the $out thing.

if [ -x $out/bin/update-mime-database -a -w $out/share/mime ]; then
XDG_DATA_DIRS=$out/share $out/bin/update-mime-database -V $out/share/mime > /dev/null
fi

if [ -x $out/bin/gtk-update-icon-cache -a -f $out/share/icons/hicolor/index.theme ]; then
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This should probably be moved to xdg.icons

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hm, I wasn't sure about that - I thought maybe there should be a GTK module that does this?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Right, that looks like GTK thing: https://developer.gnome.org/gtk3/stable/gtk-update-icon-cache.html

We should probably get a module later.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Similarly for the glib schemas.

@michaelpj michaelpj force-pushed the imp/freedesktop-modules branch 2 times, most recently from bde1594 to e551e1b Compare August 15, 2018 23:02
@michaelpj
Copy link
Contributor Author

Comments addressed. I put back the test that the target directory be writable in the fragments. I also fixed a mistake with the menus and menus/applications-merged directories - those should have been under /etc/xdg.

@@ -0,0 +1,25 @@
{ config, lib, pkgs, ... }:
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Still some unused pkgs args.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Removed.

@michaelpj
Copy link
Contributor Author

Hold off this for a bit while I do some more testing.

@michaelpj
Copy link
Contributor Author

Okay, it turns out that linking /share is very important, and many applications rely on it. That seems potentially kind of problematic, but I've left it in for now. Many DEs already provided this setting, and it's likely that anything that didn't was quite broken.

At this point, a diff of my system-path built with and without this reveals only the previously missing XDG menu dirs.

@michaelpj
Copy link
Contributor Author

(so I'm fairly confident in this now)

@@ -0,0 +1,31 @@
{ config, lib, pkgs, ... }:
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This module might also add shared-mime-info to environment.systemPackages to be linked into environment to fix bugs like #39493

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Aha, good catch. I had thought I could get away with removing them since the use of the binary is now encoded here, but it seems like it also has data to install.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fixed.

@jtojnar
Copy link
Contributor

jtojnar commented Aug 16, 2018

Okay, it turns out that linking /share is very important, and many applications rely on it. That seems potentially kind of problematic, but I've left it in for now. Many DEs already provided this setting, and it's likely that anything that didn't was quite broken.

Those applications are broken then. I intend to remove /share from GNOME and replace it with specific directories like /share/gnome-shell/extensions and /share/gnome-shell/search-providers. Other DEs should do so as well.

@jtojnar
Copy link
Contributor

jtojnar commented Aug 16, 2018

Also, similar to icons, we might want to have sounds, as per sound-theme-spec (for /share/sounds). And appstream AppStream for /share/appdata and /share/metainfo.

@michaelpj
Copy link
Contributor Author

Those applications are broken then. I intend to remove /share from GNOME and replace it with specific directories like /share/gnome-shell/extensions and /share/gnome-shell/search-providers.

I think that's a good idea, but I think we can do it as future work.

Also, similar to icons, we might want to have sounds, as per sound-theme-spec (for /share/sounds). And appstream AppStream for /share/appdata and /share/metainfo.

Sure, but let's do follow-ups. As an aside, it looks like we install a bunch of stuff in /share/sounds that doesn't follow the spec.

@jtojnar
Copy link
Contributor

jtojnar commented Aug 16, 2018

I think that's a good idea, but I think we can do it as future work.

Yeah, but I would leave it localized in the DE modules that need it, not move it up to xserver.

Sure, but let's do follow-ups. As an aside, it looks like we install a bunch of stuff in /share/sounds that doesn't follow the spec.

Sounds good.


By the way, do we need to write docs for manual or release notes?

@michaelpj
Copy link
Contributor Author

michaelpj commented Aug 16, 2018

I don't think we should leave the linking of /share to individual DEs. There are a lot of applications that have data that doesn't get linked without it, and I suspect things will just be subtly broken if you don't have it.

I don't think we need a doc change, this should only make things work better. However, I forgot to ask: should we consider having the default for some of these modules be not enabled? That would mean that systems without X could get away with e.g. not having icons, which might shrink closures a bit. OTOH, then we would definitely need a release note, since some things might rely on it happening implicitly.

@michaelpj
Copy link
Contributor Author

For example, I noticed this because /share/sddm wasn't linked, causing it to not work properly. That means that if we take it out, anyone using sddm without a DE will be broken. Of course, the correct fix is for the sddm module to link it, but I don't want to do all those fixes here.

@michaelpj
Copy link
Contributor Author

This is the diff between the profiles - as you can see, a lot of stuff goes missing.

diff --brief -r /nix/store/9mj6n7ggca7r6d82sdjvjpd4rl8c01m3-system-path /nix/store/1rfgr9cwxh7n535fqv8ldcmahpbj7v0j-system-path | grep "Only in" > missing.txt

missing.txt

@jtojnar
Copy link
Contributor

jtojnar commented Aug 16, 2018

I don't think we should leave the linking of /share to individual DEs. There are a lot of applications that have data that doesn't get linked without it, and I suspect things will just be subtly broken if you don't have it.

Moving it up in the chain would make the future granularization harder as more bugs would be obscured until then. I think status quo is good enough for now.

should we consider having the default for some of these modules be not enabled? That would mean that systems without X could get away with e.g. not having icons, which might shrink closures a bit. OTOH, then we would definitely need a release note, since some things might rely on it happening implicitly.

Hmm,

$ nix path-info -f . -S shared-mime-info
/nix/store/g89z1wlss6dnhcvajxmn36nbayql80rh-shared-mime-info-1.10	   48303016
$ nix path-info -f . -S desktop-file-utils
/nix/store/i6iglvwcq294nyam49h0q04aqzjzqf2c-desktop-file-utils-0.23	   39642584

But looks like it is mostly just glibc, libxml2 and glib. Perhaps @vcunat can address this.

For example, I noticed this because /share/sddm wasn't linked, causing it to not work properly. That means that if we take it out, anyone using sddm without a DE will be broken. Of course, the correct fix is for the sddm module to link it, but I don't want to do all those fixes here.

I would leave this as is and address this in further PR.

This is the diff between the profiles - as you can see, a lot of stuff goes missing.

diff --brief -r /nix/store/9mj6n7ggca7r6d82sdjvjpd4rl8c01m3-system-path /nix/store/1rfgr9cwxh7n535fqv8ldcmahpbj7v0j-system-path | grep "Only in" > missing.txt

missing.txt

In my experience, most apps compile in the path. Only minority looks up their own data in $XDG_DATA_DIRS. I can recall quodlibet looking for translations in there because the Python package installation method they use does not support absolute installation paths.

@michaelpj
Copy link
Contributor Author

Hm, I was thinking that we would save on closures by not linking /share/icons, but while this would shrink the size of the system environment tree it wouldn't save on the closure unless the icons were in a separate output.

@michaelpj
Copy link
Contributor Author

I've returned the linking of /share to the DEs that had it before, with a note that they shouldn't do that.

@michaelpj
Copy link
Contributor Author

In case it wasn't clear from my comment before: since there's unlikely to be a closure size improvement, I think we should leave these options enabled by default.

Copy link
Contributor

@jtojnar jtojnar left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Great job. Looks good to me, though I would still like another set of eyes to check this.

@michaelpj
Copy link
Contributor Author

@vcunat could you have a look at the final state of this?

@@ -81,6 +81,12 @@ in
description = "List of additional package outputs to be symlinked into <filename>/run/current-system/sw</filename>.";
};

extraSetup = mkOption {
type = types.lines;
default = [ ];
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nit: I think using an empty string as the default value is strictly more correct.

Copy link
Contributor Author

@michaelpj michaelpj Aug 20, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fixed, thanks.

@michaelpj
Copy link
Contributor Author

ping

@jtojnar
Copy link
Contributor

jtojnar commented Aug 21, 2018

It is still in some reviewers’ queues. Let’s leave it one more week.

@jtojnar jtojnar added this to the 18.09 milestone Aug 21, 2018
@michaelpj
Copy link
Contributor Author

Wasn't intending to be pushy, just thought we'd got pretty close :)

@samueldr
Copy link
Member

samueldr commented Aug 22, 2018

Don't hang the reviews and merging on this issue, but I'm wondering why the *.enable options have default = true, but are then enabled in xserver.nix, what would break defaulting them to false? (I'm not sure any of the previous conversations are relevant here.)

@michaelpj
Copy link
Contributor Author

Enabling them in xserver.nix is mainly just to signal intent, and so we could turn them off if we wanted. As for what would break if we set them to false... I'm not sure, and I'm not brave enough to try it. Especially since the benefits seems slim. Maybe a follow-up PR can try that.

@michaelpj
Copy link
Contributor Author

Ping - I think this would be a reasonable inclusion for 18.09.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

6 participants