Package Details: libinput-git 1.1.1.r1.g09a2967-1

Git Clone URL: https://aur.archlinux.org/libinput-git.git (read-only)
Package Base: libinput-git
Description: A library to handle input devices in Wayland compositors
Upstream URL: http://freedesktop.org/wiki/Software/libinput/
Licenses: MIT
Conflicts: libinput
Provides: libinput=1.1.1.r1.g09a2967
Submitter: klusark
Maintainer: klusark
Last Packager: klusark
Votes: 5
Popularity: 0.046957
First Submitted: 2014-01-28 17:26
Last Updated: 2015-11-24 20:59

Required by (28)

Sources (1)

Latest Comments

klusark commented on 2015-04-22 17:15

thx1138: Look at pacman-git, it hasn't been updated since 2013, and it's maintained by an Arch developer.

thx1138 commented on 2015-04-17 22:41

> the version is set automatically on build.

Yes it is. Which means someone has to actually _build_ the package to discover what the current version is.

> What use case do you have that the version on the AUR matters?

Determining whether the git version is more recent, or significantly more recent, than the standard Arch version of the same package. Currently, the git version is not significantly more recent than the Arch version. But how would you know? This is why, for instance, the AUR search page prominently displays a "Version" column in the output. "libinput-git" prominently informs the person searching that the currently available version is "0.5.0..."

Which is wrong. Which is why it is rude to mis-manage information used by an automated search tool.

Also, tools like "yaourt" use the version information to determine whether a package update is available. "yaourt" will prominently inform the searcher that _no_ libinput-git update is available whenever the git version changes. Which is wrong. Which, again, is why it is rude, to mis-manage information used by an automated search tool.

You can "blame" the AUR search engine developer, or you can "blame" the yaourt developer for presenting these wrong results, but that would also be rude. These people have already been told implicitly to rely upon the version information provide by the package.

klusark commented on 2015-04-17 21:44

@thx1138, the version is set automatically on build. If you are going to use a git package you should be aware of the versioning requirements for that package. What use case do you have that the version on the AUR matters?

thx1138 commented on 2015-04-17 21:26

> 2015-01-04 04:49
> Not sure why the package was marked out of date. Everything seems okay to me.

Not that I marked it, but obviously:

AUR - Package Details: libinput-git 0.5.0.r0.gbb10ec8-1
Last Updated: 2014-09-22 00:49

vs

Extra libinput 0.13.0-2
Last Updated: 2015-04-11 07:16 UTC

Failing to update the "pkgver" is just rude.

Scimmia commented on 2015-04-02 03:05

If you don't remember changing it, you might want to check for makepkg.conf.pacnew. libtool used to be the default, but that changed a while ago. While you're at it, you might want to check the rest of the system for pacnew files if you're not in the habit of merging them right away.

haagch commented on 2015-04-01 18:53

Indeed, I had libtool in OPTIONS instead of !libtool. Weird, I don't remember ever changing this.

Thanks for the hint, I didn't think of that.

Scimmia commented on 2015-04-01 14:26

@haagch, that's a libtool file, which is removed from the package by default. If you've changed this default in your makepkg.conf, you'll need to rebuild a number of packages from the main repos to get the libtool files back.

haagch commented on 2015-04-01 11:35

The file /usr/lib/libinput.la contains:
dependency_libs=' -lmtdev /usr/lib/libudev.la -lcap -ldw -ldl -levdev -lrt -lm'

But there is no /usr/lib/libudev.la on my system. So everything that links to libinput can't be built as long as this file exists...

klusark commented on 2015-01-04 04:49

Not sure why the package was marked out of date. Everything seems okay to me.

klusark commented on 2014-06-30 02:28

@Scimmia. Thanks for the suggestion. Both changes done.

All comments