Arch Linux User Repository

@Scimmia: or "sddm-git" doesn't work with mine. But well, since I'm not even using this package anymore, you can adopt it and update it.

Strong reason? How about that your package doesn't work with sddm-git? Seems pretty strong.

@Scimmia: "supposed to be paying attention", exactly. People are also supposed to abide by the law, yet prisons are full ;-) I guess we have 2 different point of views here: "being overzealous/overcareful for future packages/modifications and trying to prevent careless users from shooting themselves in the foot" vs "blindly trusting the users to do the right things and keeping things simple". I used to agree with you, but I ended up changing my mind after seeing that many users did not fully understand what installing VCS packages implies (especially when some programs only have a VCS package in the AUR). If you can give me a strong reason to change that (other than the philosophical differences that we may have already discussed), I will. In the meantime, it actually helped some people making the transition to the new AUR sddm packages.

@bchretien, you have a gross misunderstanding of VCS packages. The user is supposed to be paying attention to upstream when using them and doing their own updates. Users who use VCS packages and rely totally on a AUR helper to tell them when to update are doing things very wrong that that is their own fault. As for two versions being available, that's true, but they both satisfy your version requirement, so that arguement is moot.

@Spyhawk: the issue with VCS PKGBUILDs is that they don't need to be updated at every commit. Most of the time, maintainers leave them as is, even after new releases with API/ABI/file structure breaking changes. Users are not noticed and they need to remember updating their VCS-based packages. Take the following example: sddm 0.10.0 breaks their file organization again. "sddm" is updated to 0.10.0, and the themes are updated without any version requirements. So everything works fine for "sddm" users, but users that installed "sddm-git" are not noticed, they updated the themes as suggested by the AUR helpers, and they end up not being able to login with their favorite sddm theme. It all comes down on the sddm-git maintainer. Most maintainers do their job with a bump when there's a new release, but it's far from being a rule of thumb on the AUR. That's a problem I encountered several times with other packages I maintain(ed), and having the explicit versions made things much easier for both users and maintainers. This is even advised in the guidelines available on the Arch Wiki: https://wiki.archlinux.org/index.php/PKGBUILD#provides Thus, if there's a problem with the VCS version, the user is warned when building the package, not when he's booting his system. Another example: they add a new commit to master that break these themes (or other hypothetical packages that depend on it). If sddm-git's PKGBUILD is fixed, then we can simply add an extra check in the themes, else the sddm-git users can't be warned. I also know some people who don't rely on AUR helpers (I find it crazy and don't really get why, but that's a fact...). Although, "forcing" them to choose an helper by making things more complicated for them is tempting, indeed. @Scimmia: you can do both, these are not exclusive. And there's nothing preventing people from adding extra versions of sddm later on. Technically, there's already 2 available.

It's correct, but providing <pkg>=$pkgver is correct, too. That said, the problem really is the totally unnecessary version requirement here. Version requirements are only useful if more than one version is available either in the repos or in the AUR. Since that's not the case, you're just making problems.

@Spyhawk: once again, it is possible to install it with sddm-git as long as the PKGBUILD is fixed (I commented twice on the package already, still waiting for a reaction of the maintainer). I just tested, and it works smoothly.

@Spyhawk: except that AFAIK, AUR helpers do not warn you if a package disappeared from the AUR when updating (at least not yaourt), which is what happened to sddm-qt5. Moreover, some Arch-based distributions could be using the previous release for a few days before making their update. If there is some missing information in a PKGBUILD, then this PKGBUILD should be fixed. Not the ones that depend on it.