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

libayatana-appindicator: init at 0.5.4 libayatana-indicator: init at 0.6.3 ayatana-ido: init at 0.4.90 #88783

Merged
merged 3 commits into from Aug 7, 2020

Conversation

NickHu
Copy link
Contributor

@NickHu NickHu commented May 24, 2020

Motivation for this change

Adds the libayatana-appindicator library, which supersedes the
deprecated libappindicator library.

Things done
  • Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS linux)
  • 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 nixpkgs-review --run "nixpkgs-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)
  • Ensured that relevant documentation is up to date
  • Fits CONTRIBUTING.md.

@@ -0,0 +1,49 @@
{ stdenv, fetchFromGitHub, lib
, pkgconfig, autoreconfHook , gtk-doc
, gtkVersion ? "3"
Copy link
Member

Choose a reason for hiding this comment

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

Typically this is done with something like withGtk3 ? true -- if withGtk3 then gtk3 else gtk2 and similar logic. This prevents the need to check gtkVersion == "3" and gtkVersion == "2", and also handles the case of somebody specifying gtkVersion = "1" (because there's no way to do that with withGtk3 -- it's either 2 or 3).

Same with the other files.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I wasn't aware that these variables have conventions, I just followed what libappindicator did to be consistent; it makes sense for them both to match no, seeing as they are compatible libraries?

Copy link
Member

Choose a reason for hiding this comment

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

You do what you think is best, but I would personally prefer the proposed method (and don't see the fact that it's compatible as a reason to carry around cruft in a new package).

@@ -12573,6 +12575,10 @@ in
libappindicator-gtk3 = libappindicator.override { gtkVersion = "3"; };
libappindicator = callPackage ../development/libraries/libappindicator { };

libayatana-appindicator-gtk2 = libayatana-appindicator.override { gtkVersion = "2"; };
libayatana-appindicator-gtk3 = libayatana-appindicator.override { gtkVersion = "3"; };
libayatana-appindicator = callPackage ../development/libraries/libayatana-appindicator { };
Copy link
Member

Choose a reason for hiding this comment

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

Nit: I think it would make more sense to move the "base" package above the others (despite libappindicator not doing that just a few lines above).

@@ -13008,6 +13014,10 @@ in
libindicator-gtk3 = libindicator.override { gtkVersion = "3"; };
libindicator = callPackage ../development/libraries/libindicator { };

libayatana-indicator-gtk2 = libayatana-indicator.override { gtkVersion = "2"; };
libayatana-indicator-gtk3 = libayatana-indicator.override { gtkVersion = "3"; };
libayatana-indicator = callPackage ../development/libraries/libayatana-indicator { };
Copy link
Member

Choose a reason for hiding this comment

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

Same as above: please move the "base" package above the overrides.

@Ericson2314
Copy link
Member

Ericson2314 commented Aug 7, 2020

@cole-h Let's get those in a separate PR. It's more useful to match the interface as this PR does for a smooth migration, even if that means miming dubious things, and then clean up both interfaces after.

We could commute the steps too: clean up the old library's interface, and then add the new library matching the now--improved interface. That's not necessary better or worse---the important thing being the smooth transition. But given that this PR already exists, I'd say that tips the scales so it's land this then cleanup.

@Ericson2314 Ericson2314 merged commit 0bb1b89 into NixOS:master Aug 7, 2020
description = "Ayatana Application Indicators Shared Library";
homepage = "https://github.com/AyatanaIndicators/libayatana-appindicator";
changelog = "https://github.com/AyatanaIndicators/libayatana-appindicator/blob/${version}/ChangeLog";
license = [ licenses.gpl3 licenses.lgpl21 ];
Copy link
Contributor

Choose a reason for hiding this comment

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

gpl3 is unclear, use gpl3Plus or gpl3Only. See https://discourse.nixos.org/t/lib-licenses-gpl3-co-are-now-deprecated/8206 for more details.

--replace "codegendir pygtk-2.0" "codegendir pygobject-2.0"
'';

nativeBuildInputs = [ pkgconfig autoreconfHook gtk-doc ];
Copy link
Contributor

Choose a reason for hiding this comment

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

In new expressions, pkg-config should be used instead of the pkgconfig alias.


nativeBuildInputs = [ pkgconfig autoreconfHook gtk-doc ];

buildInputs = [ dbus-glib python2 python2Packages.pygtk ]
Copy link
Contributor

Choose a reason for hiding this comment

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

pygtk is GTK 2 only.

changelog = "https://github.com/AyatanaIndicators/libayatana-appindicator/blob/${version}/ChangeLog";
license = [ licenses.gpl3 licenses.lgpl21 ];
maintainers = [ maintainers.nickhu ];
platforms = platforms.x86_64;
Copy link
Contributor

Choose a reason for hiding this comment

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

Is aarch64 not supported?

sha256 = "0bqjqb7gabdk7mifk8azi630qw39z978f973fx2ylgdgr4a66j1v";
};

patchPhase = ''
Copy link
Contributor

Choose a reason for hiding this comment

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

Overriding patchPhase breaks patches field. Use prePatch or postPatch instead.

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

4 participants