Hullo Leo,
On 09/03/2016, Leo Famulari <l...@famulari.name> wrote:
> Except where necessary for the new version to work, it's best to do
> updates in a separate commit from other changes.
>
> I can apply the update myself if you say it's okay to do on its own, or
> feel free to submit a revised patch set.
Er, no. This whole thing is pretty — what's the eufemism — atomic:
PackageKit support is a ‘new’ upstream addition. Guix doesn't ship a
PackageKit expression. Nor would writing one add much value, since its
sole purpose is to serve as an abstraction layer for other, ‘impure’
package managers[1].
I therefore simply disabled it.
> Does 'src/ui.c' cause problems for us? I'd rather not make changes to
> upstream code except when necesssary [0], at least not without
> discussing it with upstream first.
However, a stale file (src/ui.c) in the tarball still references packagekit:
make[1]: Entering directory
'/tmp/guix-build-simple-scan-3.19.91.drv-0/build/src'
CC simple_scan-ui.o
../../simple-scan-3.19.91/src/ui.c:28:41: fatal error: \
packagekit-glib2/packagekit.h: No such file or directory
#include "packagekit-glib2/packagekit.h"
Simply adding ‘make clean’ doesn't work (because that assumes we're
building in the source directory and Guix doesn't). Removing the
offending file fixes the build & seemed more clear.
> [0] [...] The impact of the change should be
> well-understood by reviewers, at the very least ;)
Would a simple s/PackageKit support/newly-introduced &/ on the commit
message make this clear? Or should I be more verbose?
Kind regards,
T G-R
[1] Simple Scan then invokes PackageKit to automagically install
missing sane backends.
